Datenbank-Trigger – was ist das, und wann sollte ich einen einsetzen (und wann besser nicht)?

Ein Trigger ist eine gespeicherte Aktion, die das DBMS automatisch ausführt, sobald ein bestimmtes Ereignis an einer Tabelle passiert – typischerweise ein INSERT, UPDATE oder DELETE. Du legst fest, ob er BEFORE oder AFTER dem Ereignis feuert.

• Beispiel Protokollierung: Immer wenn eine Zeile in „Konto“ geändert wird, schreibt ein AFTER-UPDATE-Trigger automatisch den alten und neuen Wert in eine „Konto_Historie“-Tabelle. Der Anwendungsentwickler muss daran nie wieder denken.
• Beispiel Konsistenz: Ein BEFORE-INSERT-Trigger setzt ein Feld wie „erstellt_am“ oder prüft/normalisiert einen Wert, bevor er gespeichert wird.

Der entscheidende Vorteil gegenüber „mach ich in der Anwendung“: Der Trigger greift immer – egal, ob die Änderung aus deiner App, aus einem Import-Skript oder von Hand im SQL-Client kommt. Die Regel sitzt zentral an der Datenbank, nicht verstreut in jeder Anwendung, die draufzugreift.

Genau das ist der Punkt – und zugleich die Kehrseite, deshalb die Frage „wann besser nicht“ 😄 Trigger haben einen ernsten Nachteil: versteckte Logik.

• Ein Trigger läuft unsichtbar mit. Wenn ein simples UPDATE plötzlich drei weitere Tabellen verändert oder einen Fehler wirft, sucht man sich beim Debuggen dumm und dämlich, weil im Anwendungscode nichts davon steht.
• Trigger, die weitere Änderungen auslösen, können Kaskaden oder sogar Endlosschleifen erzeugen, und sie kosten bei Massen-Updates Performance (sie feuern pro betroffener Zeile bzw. Anweisung).

Faustregel aus der Praxis: Trigger sind stark für datennahe, tabellenübergreifende Automatik (Historisierung, Audit-Log, Integrität, die kein Fremdschlüssel abbildet). Fachliche Geschäftslogik gehört dagegen eher in die Anwendung bzw. eine klar aufgerufene Stored Procedure, wo man sie sieht und testen kann. Sparsam einsetzen und gut dokumentieren – dann sind sie ein Segen statt einer Falle.