Trigger sinnvoll und sparsam einsetzen

1. Was ein Trigger ist und wann er sinnvoll ist

Ein Trigger ist prozeduraler Code, den die Datenbank automatisch ausführt, sobald ein bestimmtes Ereignis an einer Tabelle eintritt, etwa ein INSERT, UPDATE oder DELETE. Anders als ein CHECK-Constraint, der auf einfache logische Bedingungen beschränkt ist, kann ein Trigger beliebige prozedurale Logik enthalten: andere Tabellen lesen und schreiben, Werte berechnen, Ausnahmen auslösen. Diese Mächtigkeit ist zugleich der Grund, warum ein Trigger mit Bedacht eingesetzt werden sollte, denn er wirkt implizit, ohne dass ein Aufrufer im Anwendungscode ihn direkt sieht.

Ein Trigger ist dann sinnvoll, wenn eine Regel unabhängig vom Zugriffsweg gelten muss und sich nicht in einem einfachen Constraint ausdrücken lässt. Typische Einsatzfälle sind Audit-Trails, die jede Änderung protokollieren, die Pflege denormalisierter Aggregatwerte über mehrere Tabellen hinweg, oder die Durchsetzung von Invarianten, die mehrere Zeilen oder Tabellen gleichzeitig betreffen. Ein Trigger ist dagegen die falsche Wahl, wenn er allgemeine Business-Logik implementiert, die besser sichtbar im Anwendungscode aufgehoben wäre, etwa Versandbenachrichtigungen oder komplexe Workflow-Entscheidungen.

Die Faustregel für den sparsamen Einsatz lautet: Ein Trigger sollte kurz, deterministisch und auf genau eine Aufgabe fokussiert sein. Sobald ein Trigger beginnt, mehrere fachliche Verantwortlichkeiten zu übernehmen, wird er zur Blackbox, die neue Teammitglieder erst mühsam entdecken müssen, weil sie beim Lesen des Anwendungscodes keinen Hinweis auf seine Existenz finden. Die folgenden Abschnitte zeigen konkrete Muster, in denen ein Trigger den größten Nutzen bringt, und die Fallstricke, die ihn sonst zum Wartungsrisiko machen.

2. BEFORE vs AFTER Trigger: Unterschiede und Einsatzzwecke

Ein BEFORE-Trigger läuft, bevor die Datenbank die Zeile tatsächlich schreibt. Er darf die NEW-Werte der Zeile noch verändern, bevor sie persistiert werden, was ihn zum natürlichen Ort für Normalisierung und Validierung macht: eine E-Mail-Adresse in Kleinschreibung umwandeln, einen berechneten Wert vorab setzen, oder eine Ausnahme auslösen, um den gesamten Schreibvorgang abzubrechen, wenn eine fachliche Regel verletzt ist. Ein BEFORE-Trigger verhindert also, dass eine ungültige Zeile überhaupt in die Tabelle gelangt.

Ein AFTER-Trigger läuft, nachdem die Zeile bereits geschrieben wurde. Er kann die geschriebenen Werte nicht mehr verändern, eignet sich dafür aber ideal für Seiteneffekte, die auf der bereits bestätigten Zeile aufbauen: einen Audit-Log-Eintrag schreiben, einen Zähler in einer verwandten Tabelle aktualisieren, oder eine Benachrichtigung in eine Warteschlangen-Tabelle einreihen. Der entscheidende Unterschied für die Wahl zwischen BEFORE und AFTER ist also die Frage, ob der Trigger die eigentliche Zeile noch beeinflussen muss, oder ob er lediglich auf eine bereits feststehende Änderung reagiert.

Ein häufiger Fehler ist, Validierungslogik in einen AFTER-Trigger zu legen und dort eine Exception auszulösen, um den Schreibvorgang rückgängig zu machen. Das funktioniert zwar über ein implizites Rollback der Transaktion, verschwendet aber Rechenzeit für einen Schreibvorgang, der ohnehin verworfen wird, und verkompliziert die Fehlerbehandlung unnötig. Validierung gehört grundsätzlich in einen BEFORE-Trigger, Seiteneffekte in einen AFTER-Trigger.

3. Row-Level vs Statement-Level Trigger

Ein Row-Level-Trigger feuert einmal für jede betroffene Zeile eines INSERT, UPDATE oder DELETE. Bei einem Bulk-Update von zehntausend Zeilen bedeutet das zehntausend einzelne Trigger-Ausführungen, was bei aufwendiger Logik im Trigger spürbar zur Gesamtlaufzeit beiträgt. MySQL unterstützt ausschließlich Row-Level-Trigger, PostgreSQL und Oracle bieten zusätzlich Statement-Level-Trigger, die genau einmal pro Anweisung feuern, unabhängig davon, wie viele Zeilen betroffen sind.

PostgreSQL erlaubt seit Version 10 zusätzlich Transition Tables über REFERENCING NEW TABLE AS ... OLD TABLE AS ..., mit denen ein Statement-Level-Trigger auf die gesamte Menge der geänderten Zeilen als virtuelle Tabelle zugreifen kann. Das ist erheblich effizienter als zehntausend einzelne Row-Level-Aufrufe, wenn die Trigger-Logik ohnehin über die gesamte Menge aggregiert, etwa für eine Zusammenfassungsstatistik nach einem Bulk-Import. Die Wahl zwischen Row-Level und Statement-Level ist damit direkt eine Performance-Entscheidung, nicht nur eine syntaktische Variante.

-- PostgreSQL: statement-level trigger using a transition table,
-- fires once per statement instead of once per row
CREATE TABLE order_import_stats (
    import_id     BIGINT NOT NULL,
    rows_inserted INT NOT NULL,
    logged_at     TIMESTAMP NOT NULL DEFAULT now()
);

CREATE OR REPLACE FUNCTION log_bulk_import_stats()
RETURNS TRIGGER AS $$
BEGIN
    -- new_rows behaves like a regular table for the whole batch
    INSERT INTO order_import_stats (import_id, rows_inserted)
    SELECT current_setting('app.import_id')::BIGINT, COUNT(*)
    FROM new_rows;
    RETURN NULL;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_order_bulk_stats
    AFTER INSERT ON orders
    REFERENCING NEW TABLE AS new_rows
    FOR EACH STATEMENT
    EXECUTE FUNCTION log_bulk_import_stats();

4. Audit-Trail mit Triggern sauber umsetzen

Ein Audit-Trail ist der am häufigsten begründete Einsatzzweck für einen Trigger, weil er unabhängig vom Zugriffsweg garantieren muss, dass jede Änderung protokolliert wird, egal ob sie über die Hauptanwendung, ein Admin-Skript oder einen direkten SQL-Client erfolgt. Ein AFTER-Trigger auf INSERT, UPDATE und DELETE schreibt dabei den alten und neuen Zustand der Zeile in eine separate Audit-Tabelle, meist zusammen mit Zeitstempel und ausführendem Datenbankbenutzer.

Für die Speicherung des Zustands eignet sich in PostgreSQL der Typ JSONB in Kombination mit row_to_json oder to_jsonb, weil er beliebige Spaltenänderungen erfasst, ohne dass die Audit-Tabelle bei jeder Schema-Änderung der Ausgangstabelle angepasst werden muss. Dieses Muster entkoppelt den Audit-Trail vom konkreten Schema und macht ihn robust gegenüber zukünftigen Spaltenerweiterungen.

-- PostgreSQL: generic audit trail trigger, schema-agnostic via JSONB
CREATE TABLE audit_log (
    audit_id    BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    table_name  TEXT NOT NULL,
    operation   TEXT NOT NULL,
    old_values  JSONB,
    new_values  JSONB,
    changed_by  TEXT NOT NULL DEFAULT current_user,
    changed_at  TIMESTAMP NOT NULL DEFAULT now()
);

CREATE OR REPLACE FUNCTION audit_row_change()
RETURNS TRIGGER AS $$
BEGIN
    IF TG_OP = 'DELETE' THEN
        INSERT INTO audit_log (table_name, operation, old_values)
        VALUES (TG_TABLE_NAME, TG_OP, to_jsonb(OLD));
        RETURN OLD;
    ELSIF TG_OP = 'UPDATE' THEN
        INSERT INTO audit_log (table_name, operation, old_values, new_values)
        VALUES (TG_TABLE_NAME, TG_OP, to_jsonb(OLD), to_jsonb(NEW));
        RETURN NEW;
    ELSE
        INSERT INTO audit_log (table_name, operation, new_values)
        VALUES (TG_TABLE_NAME, TG_OP, to_jsonb(NEW));
        RETURN NEW;
    END IF;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_customer_audit
    AFTER INSERT OR UPDATE OR DELETE ON customer
    FOR EACH ROW EXECUTE FUNCTION audit_row_change();

5. Validierung und Normalisierung mit BEFORE Triggern

Ein BEFORE-Trigger eignet sich für Regeln, die über die Möglichkeiten eines CHECK-Constraints hinausgehen, etwa eine Prüfung gegen eine andere Tabelle oder eine Berechnung, die von mehreren Zeilen abhängt. Ein Beispiel ist die Prüfung, ob ein Rabattcode noch gültig ist, bevor eine Bestellzeile geschrieben wird. Ein CHECK-Constraint kann diese Prüfung nicht ausdrücken, weil er nicht auf andere Tabellen zugreifen darf, ein BEFORE-Trigger dagegen schon.

Normalisierung ist der zweite häufige Einsatzzweck: ein BEFORE-Trigger kann eine E-Mail-Adresse konsequent in Kleinschreibung umwandeln, führende und folgende Leerzeichen entfernen, oder einen abgeleiteten Wert wie ein Suchindex-Feld vorab berechnen. Diese Normalisierung direkt im Trigger stellt sicher, dass sie unabhängig davon greift, ob die Anwendung, ein Import-Skript oder ein manueller Datensatz die Zeile schreibt.

-- PostgreSQL: BEFORE trigger for normalization and cross-table validation
CREATE OR REPLACE FUNCTION validate_and_normalize_order()
RETURNS TRIGGER AS $$
DECLARE
    v_discount_valid BOOLEAN;
BEGIN
    -- normalize before the row is written
    NEW.customer_email := lower(trim(NEW.customer_email));

    -- cross-table check a CHECK constraint could never express
    IF NEW.discount_code IS NOT NULL THEN
        SELECT EXISTS (
            SELECT 1 FROM discount_code
            WHERE code = NEW.discount_code AND valid_until >= now()
        ) INTO v_discount_valid;

        IF NOT v_discount_valid THEN
            RAISE EXCEPTION 'Discount code % is invalid or expired', NEW.discount_code;
        END IF;
    END IF;

    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_order_validate
    BEFORE INSERT OR UPDATE ON orders
    FOR EACH ROW EXECUTE FUNCTION validate_and_normalize_order();

6. Trigger-Rekursion und Mutating-Table-Probleme

Ein Trigger, der die eigene Tabelle oder eine Tabelle verändert, auf der ein weiterer Trigger definiert ist, kann eine Kaskade auslösen, die im ungünstigsten Fall in einer Endlosschleife endet. Oracle nennt dieses Problem explizit "mutating table error", wenn ein Row-Level-Trigger versucht, die gerade in Bearbeitung befindliche Tabelle abzufragen, während PostgreSQL und MySQL das grundsätzlich erlauben, aber ebenfalls in eine unkontrollierte Rekursion laufen können, wenn ein Trigger auf UPDATE dieselbe Tabelle erneut per UPDATE verändert.

Der robuste Schutz gegen diese Fallen ist eine explizite Rekursionssperre über eine Session-Variable, oder in PostgreSQL über pg_trigger_depth(), das die aktuelle Verschachtelungstiefe der Trigger-Ausführung zurückgibt. Ein Trigger, der prüft, ob er bereits innerhalb eines anderen Trigger-Aufrufs läuft, kann seine eigene Logik gezielt überspringen und so eine Endlosschleife verhindern, ohne die Kaskadierung für den regulären Anwendungsfall zu blockieren.

-- PostgreSQL: guard against unwanted trigger recursion using pg_trigger_depth()
CREATE OR REPLACE FUNCTION recalc_order_total()
RETURNS TRIGGER AS $$
BEGIN
    -- skip if this trigger call is itself nested inside another trigger
    IF pg_trigger_depth() > 1 THEN
        RETURN NEW;
    END IF;

    UPDATE orders
    SET total_amount = (
        SELECT COALESCE(SUM(quantity * unit_price), 0)
        FROM order_line WHERE order_id = NEW.order_id
    )
    WHERE order_id = NEW.order_id;

    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_order_line_recalc
    AFTER INSERT OR UPDATE OR DELETE ON order_line
    FOR EACH ROW EXECUTE FUNCTION recalc_order_total();

7. Performance-Auswirkungen von Triggern

Ein Trigger kostet Rechenzeit bei jedem betroffenen INSERT, UPDATE oder DELETE, und dieser Kostenfaktor multipliziert sich bei Row-Level-Triggern mit der Anzahl betroffener Zeilen. Ein Bulk-Import von einer Million Zeilen mit einem aufwendigen Row-Level-Trigger kann die Laufzeit um ein Vielfaches gegenüber demselben Import ohne Trigger verlängern, besonders wenn der Trigger selbst weitere Abfragen gegen andere Tabellen ausführt.

Für sehr große, kontrollierte Bulk-Operationen, bei denen die Datenqualität bereits vorab garantiert ist, ist es ein etabliertes Muster, Trigger temporär zu deaktivieren, den Import durchzuführen, und anschließend die vom Trigger normalerweise gepflegten Werte in einem einzigen Batch nachzuberechnen. Dieses Vorgehen muss jedoch bewusst und dokumentiert erfolgen, weil in der Zwischenzeit Audit-Trail-Einträge oder Aggregatwerte fehlen, bis der Nachlauf abgeschlossen ist.

-- PostgreSQL: disable triggers for a controlled bulk load, then recompute
ALTER TABLE order_line DISABLE TRIGGER trg_order_line_recalc;

COPY order_line (order_id, product_id, quantity, unit_price)
FROM '/data/bulk_import.csv' WITH (FORMAT csv);

ALTER TABLE order_line ENABLE TRIGGER trg_order_line_recalc;

-- Recompute affected aggregates once, in a single batch statement
UPDATE orders o
SET total_amount = (
    SELECT COALESCE(SUM(ol.quantity * ol.unit_price), 0)
    FROM order_line ol WHERE ol.order_id = o.order_id
)
WHERE o.order_id IN (SELECT DISTINCT order_id FROM order_line);

8. Debugging, Wartbarkeit und Namenskonventionen

Der größte praktische Nachteil eines Trigger ist seine Unsichtbarkeit im Anwendungscode. Ein Entwickler, der ein UPDATE-Statement liest, sieht nicht automatisch, dass dieses Statement einen Kaskadeneffekt in drei weiteren Tabellen auslöst. Diese versteckte Kopplung erschwert Debugging erheblich, besonders wenn ein Fehler erst Tage später als unerklärliche Dateninkonsistenz auffällt. Eine konsequente Namenskonvention wie das Präfix trg_, kombiniert mit vollständiger Dokumentation jedes Triggers in einem zentralen Schema-Dokument, reduziert diesen Nachteil spürbar.

Ebenso wichtig ist, Trigger-Definitionen wie regulären Code in der Versionskontrolle zu pflegen, mit Migrationen statt manueller Änderungen direkt in der Produktionsdatenbank. Ein Trigger, der nur im Kopf eines einzelnen Entwicklers dokumentiert ist, wird beim nächsten Teamwechsel zur Wartungsfalle. Wer diese Disziplin einhält, kann die Mächtigkeit eines Triggers nutzen, ohne die Nachvollziehbarkeit des Gesamtsystems zu opfern.

9. Trigger vs. Alternativen: wann was verwenden

Nicht jede Regel, die sich mit einem Trigger umsetzen ließe, sollte auch als Trigger umgesetzt werden. Die folgende Übersicht zeigt, welches Werkzeug für welchen Anwendungsfall die robustere und wartbarere Wahl ist.

Ein Trigger ist genau dann die richtige Wahl, wenn eine Regel unbedingt an die Tabelle selbst gebunden sein muss, unabhängig davon, welcher Prozess schreibt. Für alles, was auch außerhalb der Datenbank sinnvoll entschieden werden kann, ist der Anwendungscode die transparentere und leichter testbare Alternative.

10. Zusammenfassung

Ein Trigger ist ein mächtiges Werkzeug für Regeln, die unabhängig vom Zugriffsweg gelten müssen, etwa Audit-Trails oder die Pflege von Aggregatwerten über mehrere Tabellen. BEFORE-Trigger eignen sich für Validierung und Normalisierung, weil sie die Zeile vor dem Schreiben noch beeinflussen können, AFTER-Trigger für Seiteneffekte auf bereits geschriebenen Daten. Row-Level-Trigger feuern pro Zeile, Statement-Level-Trigger mit Transition Tables in PostgreSQL erlauben effiziente Bulk-Verarbeitung ohne tausendfache Einzelaufrufe.

Rekursionsschutz über pg_trigger_depth(), bewusste Deaktivierung bei kontrollierten Bulk-Loads und konsequente Namenskonventionen sind die drei wichtigsten Maßnahmen, um einen Trigger performant und wartbar zu halten. Wer diese Kriterien beachtet und einen Trigger nur dort einsetzt, wo Anwendungscode die Regel nicht zuverlässig erzwingen kann, profitiert von garantierter Konsistenz, ohne die Nachvollziehbarkeit des Systems zu verlieren.

11. FAQ: Trigger sinnvoll und sparsam einsetzen