Trigger

SQL (PostgreSQL):

CREATE TRIGGER check_age
BEFORE INSERT ON users
FOR EACH ROW
EXECUTE FUNCTION verify_age();

Wenn du jetzt INSERT INTO users... machst, läuft verify_age() bevor die Daten gespeichert werden. Der Trigger kann das Speichern verhindern (z. B. wenn User zu jung).

Automation (n8n): Der Start-Node ist der Trigger.

• Cron Trigger: "Jeden Tag um 8:00".
• Webhook Trigger: "Wenn URL aufgerufen wird".
• App Trigger: "Wenn neue Zeile in Google Sheets".

1. BEFORE vs. AFTER vs. INSTEAD OF

In Datenbanken:

• BEFORE: Gut für Validierung ("Ist die Email gültig?") oder Modifikation ("Setze created_at = NOW()"). Kann das Original-Event abbrechen.
• AFTER: Gut für Logging oder Nebenläufigkeit ("Sende Email an User"). Der Datensatz ist schon sicher gespeichert (ID existiert).
• INSTEAD OF: Für Views. Man kann technisch nicht in eine View schreiben. Der Trigger fängt das INSERT ab und schreibt es in die echte Tabelle dahinter.

2. Cascading Triggers (Rekursion)

Gefahr! Trigger A ändert Tabelle B. Tabelle B hat Trigger C, der Tabelle A ändert. Tabelle A feuert wieder Trigger A. Endlosschleife. Datenbanken haben oft ein Limit (z. B. max 16 Rekursionen), dann brechen sie mit Fehler ab ("Stack Depth Limit exceeded"). In verteilten Systemen (Cloud Functions) ist das noch gefährlicher (Millionen-Rechnung, weil Lambda A Lambda B ruft und umgekehrt).

3. Performance Killer

Trigger sind "unsichtbare" Logik. Ein Entwickler wundert sich: "Warum ist mein simpler INSERT so langsam?" Er sieht nicht, dass im Hintergrund ein Trigger 50 andere Tabellen updatet und Emails sendet. Best Practice: Halte Trigger klein und schnell. Lagere komplexe Logik (Email senden) in eine Work Queue aus (Trigger schreibt nur "Job ID" in Queue, Worker macht den Rest asynchron).

1. Trigger-Kontext: OLD vs. NEW

Innerhalb eines Triggers hast du Zugriff auf zwei Pseudotabellen:

• OLD: Der Zustand der Zeile vor der Änderung (beim DELETE und UPDATE).
• NEW: Der Zustand der Zeile nach der Änderung (beim INSERT und UPDATE). Profi-Tipp: Wenn du einen Audit-Log baust, speichere nicht nur den neuen Wert, sondern berechne den Diff. So kannst du später genau sehen: "User hat nur das Feld 'Zahlungsart' geändert, den Rest nicht." Das spart massiv Speicherplatz im Vergleich zum Speichern des gesamten Datensatzes bei jeder kleinen Änderung.

2. Mutating Table Error (Oracle/Postgres Gotchas)

Ein klassischer Fehler für Fortgeschrittene: Ein Row-Level Trigger auf Tabelle A versucht, einen SELECT auf die gleiche Tabelle A zu machen, um etwas zu prüfen. Die Datenbank blockiert das oft (besonders Oracle ist hier streng), da die Tabelle sich in einem "inkonsistenten" Zustand befindet, solange die Transaktion noch läuft. Lösung: Man nutzt Statement-Level Trigger oder temporäre Hilfstabellen, um den Status zwischenzuspeichern. In PostgreSQL ist dies weniger restriktiv, kann aber zu race conditions führen, wenn man nicht genau weiß, was man tut.

3. Ersatz für Trigger: Change Data Capture (CDC)

Da Trigger Performance kosten und schwer zu debuggen sind, nutzen moderne Daten-Architekturen oft CDC. Statt dass die Datenbank einen Trigger ausführt, liest ein externes Programm (wie Debezium) direkt das Transaktions-Log der Datenbank (Transaction -> WAL). Jede Änderung wird als Event (z. B. an Kafka) gesendet. Die Datenbank spürt davon fast nichts, da das Log ohnehin geschrieben wird. Die Logik ("Sende Email bei neuem User") wandert aus der Datenbank heraus in einen Microservice. Das schont die DB-CPU und entkoppelt die Systeme.