Datenbank-Trigger (kurz: Trigger) sind spezielle automatische Aktionen in einer Datenbank, die ausgelöst werden, wenn bestimmte Ereignisse auf einer Tabelle oder Sicht (View) passieren.
Ein Trigger ist ein vordefinierter Code, der bei INSERT, UPDATE oder DELETE auf einer Tabelle automatisch ausgeführt wird – ohne dass der Benutzer ihn direkt aufruft.
Stell dir vor, du hast eine Tabelle Bestellungen
, und du willst, dass immer, wenn eine Bestellung gelöscht wird, diese Info in einer Tabelle Log
gespeichert wird.
Dann schreibst du einen DELETE-Trigger für die Tabelle Bestellungen
, der automatisch beim Löschen etwas in Log
schreibt.
Typ | Beschreibung |
---|---|
BEFORE | Wird vor der Aktion ausgeführt |
AFTER | Wird nach der Aktion ausgeführt |
INSTEAD OF | (bei Views) ersetzt die Aktion komplett |
CREATE TRIGGER log_delete
AFTER DELETE ON Bestellungen
FOR EACH ROW
BEGIN
INSERT INTO Log (aktion, zeitpunkt)
VALUES ('Bestellung gelöscht', NOW());
END;
Validierung von Daten
Automatisches Logging
Business-Logik abbilden
Referentielle Integrität erweitern
Schwer zu debuggen
Können unbemerkt viele Aktionen auslösen
Beeinflussen Performance, wenn komplex
GitHub Actions ist ein Feature von GitHub, mit dem du automatisierte Workflows für deine Softwareprojekte erstellen kannst – direkt im GitHub-Repository.
Du kannst CI/CD-Pipelines (Continuous Integration / Continuous Deployment) aufbauen, z. B.:
🛠️ Code bei jedem Push oder Pull Request builden
🚀 Software automatisch deployen (z. B. auf einen Webserver, in die Cloud, zu DockerHub)
📦 Releases erstellen (z. B. ZIP-Dateien, Versionstags)
🔄 Cronjobs oder geplante Tasks laufen lassen
GitHub Actions basiert auf sogenannten Workflows, die du in einer Datei definierst:
Die Datei heißt z. B. .github/workflows/ci.yml
Sie ist im YAML-Format
Du definierst Events (z. B. push
, pull_request
) und Jobs (z. B. build
, test
)
Jobs bestehen aus Steps, die Befehle oder Aktionen ausführen
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '20'
- run: npm install
- run: npm test
Eine Action ist ein einzelner Schritt, den man in einem Workflow ausführt. Es gibt:
Vorgefertigte Actions (z. B. actions/checkout
, setup-node
, upload-artifact
)
Eigene Actions (z. B. Shell-Skripte oder Docker-Container)
Du kannst Actions im GitHub Marketplace finden und nutzen.
Spart manuelle Arbeit
Verbessert Codequalität (durch automatisierte Tests)
Macht Deployments reproduzierbar
Alles direkt in GitHub – kein externer CI-Dienst nötig (wie Jenkins oder Travis CI)
Docker Compose ist ein Werkzeug, mit dem du mehrere Docker-Container als einen einzigen Service definieren und starten kannst. Statt jeden Container einzeln über die Docker-CLI zu starten, kannst du mit Docker Compose eine docker-compose.yml
-Datei schreiben, in der du alle benötigten Dienste (z. B. Datenbank, Webserver, App-Container) deklarierst.
Docker Compose = Projektbeschreibung + Mehrere Container + Ein Befehl zum Starten
docker-compose.yml
version: '3.9'
services:
web:
build: .
ports:
- "5000:5000"
volumes:
- .:/code
redis:
image: "redis:alpine"
In diesem Beispiel:
Ein Container baut die lokale Webanwendung.
Ein zweiter Container nutzt das offizielle Redis-Image.
Beide Container sind miteinander vernetzt.
docker-compose up # Startet alle Container im Vordergrund
docker-compose up -d # Startet im Hintergrund (detached)
docker-compose down # Stoppt und entfernt Container, Netzwerke etc.
✅ Einfaches Setup für Multi-Container-Anwendungen
✅ Alles wird in einer Datei versioniert (z. B. für Git)
✅ Reproduzierbare Entwicklungsumgebungen
✅ Leichtes Hoch- und Runterfahren ganzer Stacks
Lokale Entwicklung mit mehreren Services (z. B. App + DB)
Integrationstests mit vollständigem Stack
Simpler Deployment-Workflow (z. B. über CI/CD)
Contentful ist ein sogenanntes Headless Content Management System (Headless CMS). Es ermöglicht Unternehmen, Inhalte (Content) zentral zu verwalten und flexibel über APIs an verschiedene Ausgabekanäle auszuliefern – z. B. Websites, Apps oder digitale Displays.
Traditionelle CMS (wie WordPress) verwalten Inhalte und präsentieren sie gleichzeitig auf einer fest verknüpften Website. Bei einem Headless CMS ist die „Präsentationsschicht“ (Frontend) vom „Content-Management“ (Backend) getrennt. Man hat also nur den „Kopf“ (Frontend) abgetrennt – daher der Begriff „headless“.
API-first: Inhalte werden über REST oder GraphQL APIs bereitgestellt.
Flexibles Content Modeling: Man definiert eigene Content-Typen (z. B. Blogartikel, Produkte, Testimonials) mit frei wählbaren Feldern.
Mehrsprachigkeit: Gute Unterstützung für mehrsprachige Inhalte.
Cloud-basiert: Keine eigene Server-Infrastruktur nötig.
Integration: Lässt sich gut mit Tools wie React, Vue, Next.js, Shopify, SAP, etc. kombinieren.
Unternehmen mit mehreren Ausgabekanälen (Website, App, Smartwatch, etc.)
Große Marken mit internationaler Präsenz
Entwicklerteams, die ein flexibles und skalierbares CMS suchen
Ein Headless CMS (Content Management System) ist ein Content-Management-System, bei dem das Backend (die Inhalte und ihre Verwaltung) vom Frontend (der Darstellung für die Nutzer) vollständig getrennt ist.
Backend und Frontend sind gekoppelt.
Die Inhalte werden im System erstellt und direkt als HTML über ein fest integriertes Theme angezeigt.
Vorteil: Alles aus einer Hand.
Nachteil: Eingeschränkte Flexibilität, schwer für Multi-Plattform-Ausgabe (z. B. App + Webseite + Smartwatch).
Nur Backend.
Inhalte werden über eine API (z. B. REST oder GraphQL) bereitgestellt.
Das Frontend (z. B. eine React-Webseite, native App, Digital Signage) holt sich die Inhalte dynamisch.
Vorteil: Sehr flexibel, geeignet für Multi-Channel-Ausspielung.
Nachteil: Frontend muss separat entwickelt werden (mehr Aufwand).
Webseiten mit modernen JavaScript-Frameworks (z. B. React, Next.js, Vue)
Mobile Apps, die denselben Content wie die Website zeigen sollen
Omnichannel-Strategien: Website, App, IoT-Geräte, etc.
Contentful
Strapi
Sanity
Directus
Prismic
Storyblok (Hybrid-Ansatz mit Visual Editor)
Storyblok ist ein benutzerfreundliches, headless Content-Management-System (CMS), das Entwicklern und Marketing-Teams hilft, Inhalte schnell und effizient zu erstellen, zu verwalten und zu veröffentlichen. Es bietet eine visuelle Bearbeitungsoberfläche, die es ermöglicht, Inhalte in Echtzeit zu gestalten, und ist flexibel mit verschiedenen Frameworks und Plattformen kompatibel. Durch seine API-first-Architektur können Inhalte auf jeder digitalen Plattform ausgespielt werden, was es ideal für moderne Web- und App-Entwicklung macht.
Shopware ist ein modulares E-Commerce-System aus Deutschland, mit dem man Online-Shops erstellen und verwalten kann. Es richtet sich sowohl an kleine Händler als auch an große Unternehmen und zeichnet sich durch seine Flexibilität, Skalierbarkeit und moderne Technologie aus.
Hier ein Überblick:
Hersteller: Shopware AG (gegründet 2000 in Deutschland)
Technologie: PHP, Symfony-Framework, API-first-Ansatz
Aktuelle Version: Shopware 6 (seit 2019)
Open Source: Ja, mit kostenpflichtigen Erweiterungen
Headless-Ready: Ja, unterstützt Headless-Commerce über APIs
Produktverwaltung: Varianten, Staffelpreise, Medien, SEO
Vertriebskanäle: Webshop, POS, Social Media, Marktplätze
Content Management: Integriertes CMS (Shopping Experiences)
Zahlung & Versand: Viele Schnittstellen, z. B. PayPal, Klarna
Mehrsprachigkeit & Multi-Currency
B2B- & B2C-Features
App-System & API für Erweiterungen
Startups (kostenfreie Community Edition)
KMU und Mittelstand
Enterprise-Kunden mit individuellen Anforderungen
Besonders beliebt im deutschsprachigen Raum
Made in Germany → DSGVO-konform
Hohe Individualisierbarkeit
Aktives Ökosystem & Community
Skalierbar für wachsende Anforderungen
Ein Prepared Statement (auch vorbereitetes Statement genannt) ist eine Technik in der Programmierung, insbesondere bei der Arbeit mit Datenbanken, um SQL-Abfragen sicherer und effizienter auszuführen.
Ein Prepared Statement besteht aus zwei Schritten:
Vorbereitung der SQL-Abfrage mit Platzhaltern
Beispiel in SQL:
SELECT * FROM users WHERE username = ? AND password = ?
(In manchen Sprachen nutzt man auch :username
oder andere Platzhalter)
Bindung der Parameter und Ausführung
Die echten Werte werden später „gebunden“, z. B.:
$stmt->bind_param("ss", $username, $password);
$stmt->execute();
✅ Sicherer vor SQL-Injection:
Benutzereingaben werden nicht direkt in die SQL eingebaut, sondern separat behandelt.
✅ Schneller bei Wiederholungen:
Die SQL-Abfrage wird vom Datenbankserver einmal geparst und kann mehrfach effizient ausgeführt werden (z. B. bei Schleifen).
$conn = new mysqli("localhost", "user", "pass", "database");
$stmt = $conn->prepare("SELECT * FROM users WHERE email = ?");
$stmt->bind_param("s", $email); // "s" für string
$email = "beispiel@example.com";
$stmt->execute();
$result = $stmt->get_result();
Ein Prepared Statement trennt SQL-Logik von Benutzereingaben und schützt so vor Sicherheitslücken wie SQL-Injection. Es ist eine Best Practice beim Umgang mit Datenbanken.
Ein Outer Join ist ein Begriff aus der Datenbankabfrage (meist in SQL) und bezeichnet eine spezielle Art, zwei Tabellen miteinander zu verknüpfen – auch dann, wenn keine passenden Datensätze in einer der Tabellen vorhanden sind.
LEFT OUTER JOIN (oder einfach: LEFT JOIN):
→ Gibt alle Datensätze aus der linken Tabelle zurück, auch wenn es keine passenden Datensätze in der rechten Tabelle gibt.
→ Nicht passende Werte aus der rechten Tabelle werden mit NULL
aufgefüllt.
RIGHT OUTER JOIN (oder: RIGHT JOIN):
→ Gibt alle Datensätze aus der rechten Tabelle zurück, auch wenn es keine passenden in der linken gibt.
→ Nicht passende Werte aus der linken Tabelle werden mit NULL
ergänzt.
FULL OUTER JOIN:
→ Gibt alle Datensätze aus beiden Tabellen zurück.
→ Wo keine Übereinstimmung vorliegt, wird mit NULL
ergänzt.
Angenommen, du hast zwei Tabellen:
Kunden
Kundennr | Name |
1 | Anna |
2 | Bernd |
3 | Clara |
Bestellungen
Bestellnr | Kundennr | Produkt |
101 | 2 | Buch |
102 | 4 | Lampe |
Kundennr | Name | Bestellnr | Produkt |
---|---|---|---|
1 | Anna | NULL | NULL |
2 | Bernd | 101 | Buch |
3 | Clara | NULL | NULL |
PDO steht für PHP Data Objects und ist eine Datenbank-Abstraktionsschicht in PHP. Es handelt sich um eine objektorientierte Schnittstelle, mit der du auf verschiedene Datenbanken zugreifen kannst – z. B. MySQL, PostgreSQL, SQLite – ohne den Datenbankspezifischen Code stark ändern zu müssen.
✅ Einheitliche API:
Egal ob MySQL, SQLite oder PostgreSQL – du benutzt denselben Code-Stil.
✅ Prepared Statements:
Sicherer Schutz vor SQL-Injektionen durch gebundene Parameter:
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id");
$stmt->execute(['id' => $userId]);
✅ Transaktionen:
PDO unterstützt Transaktionen (wichtig z. B. bei Bankbuchungen).
✅ Fehlerbehandlung per Exception:
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
✅ Flexibler Datenbankwechsel:
Möchtest du von MySQL auf PostgreSQL wechseln? Meist nur der DSN-String und Treiber müssen geändert werden.
$dsn = 'mysql:host=localhost;dbname=testdb;charset=utf8mb4';
$user = 'root';
$pass = '';
try {
$pdo = new PDO($dsn, $user, $pass);
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
echo "Verbindung erfolgreich!";
} catch (PDOException $e) {
echo "Verbindung fehlgeschlagen: " . $e->getMessage();
}
PDO ist der empfohlene Weg, um in modernen PHP-Anwendungen mit Datenbanken zu arbeiten – besonders wegen der Sicherheit und Flexibilität.