SQLite Trigger: CREATE TRIGGER mit BEFORE/AFTER & OLD/NEW

Ein Trigger führt SQL automatisch aus

Ein SQLite Trigger ist ein gespeicherter SQL-Block, der immer dann ausgelöst wird, wenn ein bestimmtes Ereignis an einer bestimmten Tabelle passiert. Du schreibst ihn einmal – das „Wann" übernimmt SQLite für dich.

Der grundsätzliche Aufbau:

CREATE TABLE products (
    id INTEGER PRIMARY KEY,
    name TEXT NOT NULL,
    price REAL NOT NULL
);

CREATE TABLE price_history (
    product_id INTEGER,
    old_price REAL,
    new_price REAL,
    changed_at TEXT DEFAULT CURRENT_TIMESTAMP
);

CREATE TRIGGER log_price_change
AFTER UPDATE OF price ON products
BEGIN
    INSERT INTO price_history(product_id, old_price, new_price)
    VALUES (OLD.id, OLD.price, NEW.price);
END;

INSERT INTO products(name, price) VALUES ('Notizbuch', 5.00);
UPDATE products SET price = 6.50 WHERE name = 'Notizbuch';
SELECT * FROM price_history;

Wir haben nirgends ein explizites INSERT auf price_history ausgeführt – das hat der Trigger für uns übernommen. Jede künftige Preisänderung landet auf dieselbe Weise im Log, egal ob sie aus der CLI, einem Skript oder einer App kommt.

Aufbau von CREATE TRIGGER

Schauen wir uns die Syntax Stück für Stück an:

CREATE TRIGGER trigger_name
{ BEFORE | AFTER | INSTEAD OF } { INSERT | UPDATE [ OF column_list ] | DELETE }
ON table_name
[ FOR EACH ROW ]
[ WHEN condition ]
BEGIN
    -- eine oder mehrere Anweisungen
END;

• Timing — BEFORE läuft vor der Änderung, AFTER danach, und INSTEAD OF ersetzt sie komplett (nur bei Views).
• Event — die Operation, die den Trigger auslöst. Mit UPDATE OF col1, col2 schränkst du das Ganze auf bestimmte Spalten ein.
• Tabelle — die Tabelle, die überwacht wird.
• FOR EACH ROW — SQLite kennt ausschließlich Row-Level-Trigger, das ist also sowieso implizit. Du darfst es zur Klarheit hinschreiben, ändern tut es nichts.
• WHEN — eine optionale Bedingung. Der Trigger-Body wird nur ausgeführt, wenn sie zutrifft.
• Body — eine oder mehrere Anweisungen zwischen BEGIN und END. Jede muss mit einem Semikolon abgeschlossen werden.

Mehr Grammatik gibt's nicht. Die meisten echten Trigger kommen mit fünf bis zehn Zeilen aus.

OLD und NEW: die betroffene Zeile

Innerhalb des Bodys stehen dir zwei Pseudo-Zeilen zur Verfügung, mit denen du auf die Daten zugreifst:

• NEW — die neue Zeile. Verfügbar in INSERT- und UPDATE-Triggern.
• OLD — die bisherige Zeile. Verfügbar in UPDATE- und DELETE-Triggern.

Ein DELETE-Trigger kennt nur OLD, ein INSERT-Trigger nur NEW. Ein UPDATE-Trigger hat beide.

CREATE TABLE accounts (
    id INTEGER PRIMARY KEY,
    name TEXT,
    balance REAL NOT NULL
);

CREATE TABLE deletions (
    table_name TEXT,
    row_id INTEGER,
    snapshot TEXT,
    deleted_at TEXT DEFAULT CURRENT_TIMESTAMP
);

CREATE TRIGGER archive_account
AFTER DELETE ON accounts
BEGIN
    INSERT INTO deletions(table_name, row_id, snapshot)
    VALUES ('accounts', OLD.id, OLD.name || ' / ' || OLD.balance);
END;

INSERT INTO accounts(name, balance) VALUES ('Rosa', 120.00);
DELETE FROM accounts WHERE name = 'Rosa';
SELECT * FROM deletions;

Die gelöschte Zeile ist aus accounts verschwunden, aber ihre Daten wurden vorher in deletions festgehalten.

BEFORE UPDATE Trigger: Werte prüfen oder anpassen

Ein BEFORE-Trigger feuert, bevor die Änderung tatsächlich in die Datenbank geschrieben wird. Praktisch, um einen Fehler auszulösen oder Daten vorher noch zu normalisieren:

CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    email TEXT NOT NULL,
    created_at TEXT
);

CREATE TRIGGER lowercase_email
BEFORE INSERT ON users
BEGIN
    UPDATE users SET email = email; -- Leeroperation, dient nur zur Veranschaulichung des Kontexts
END;

CREATE TRIGGER reject_empty_email
BEFORE INSERT ON users
WHEN NEW.email IS NULL OR trim(NEW.email) = ''
BEGIN
    SELECT RAISE(ABORT, 'E-Mail darf nicht leer sein');
END;

INSERT INTO users(email) VALUES ('ada@example.com');
INSERT INTO users(email) VALUES ('');
SELECT * FROM users;

Das zweite INSERT bricht ab, bevor auch nur eine Zeile geschrieben wird. RAISE(ABORT, '...') bricht das laufende Statement ab und macht alle Änderungen daraus rückgängig — mit RAISE(FAIL, ...), RAISE(ROLLBACK, ...) und RAISE(IGNORE) steuerst du noch genauer, was passieren soll.

Für reine Datenvalidierung sind CHECK-Constraints die bessere Wahl: Sie sind deklarativ, und der Optimizer kennt sie. Ein BEFORE-Trigger lohnt sich erst dann, wenn die Regel auf andere Tabellen zugreifen muss oder etwas leisten soll, was ein CHECK nicht abbilden kann.

WHEN: Trigger mit Bedingung

Mit einer WHEN-Klausel legst du fest, welche Zeilenänderungen den Trigger-Rumpf überhaupt auslösen. Sie wird pro Zeile ausgewertet, nachdem OLD und NEW gebunden wurden:

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    total REAL NOT NULL,
    status TEXT NOT NULL
);

CREATE TABLE big_orders (
    order_id INTEGER,
    total REAL,
    flagged_at TEXT DEFAULT CURRENT_TIMESTAMP
);

CREATE TRIGGER flag_big_order
AFTER INSERT ON orders
WHEN NEW.total >= 1000
BEGIN
    INSERT INTO big_orders(order_id, total) VALUES (NEW.id, NEW.total);
END;

INSERT INTO orders(total, status) VALUES (50, 'paid');
INSERT INTO orders(total, status) VALUES (1500, 'paid');
INSERT INTO orders(total, status) VALUES (2200, 'paid');
SELECT * FROM big_orders;

Die erste Bestellung fällt durchs Raster. Die beiden anderen landen drin. Ohne die WHEN-Klausel würde jedes Insert blind in big_orders geschrieben, und du müsstest erst beim Lesen filtern.

INSTEAD OF: Views beschreibbar machen

Views sind in SQLite standardmäßig nur lesbar. Ein INSTEAD OF-Trigger fängt einen Schreibzugriff auf einen View ab und führt stattdessen dein SQL aus — meist übersetzt er den Zugriff in Schreibvorgänge auf die zugrunde liegende(n) Tabelle(n):

CREATE TABLE employees (
    id INTEGER PRIMARY KEY,
    first_name TEXT,
    last_name TEXT,
    salary REAL
);

CREATE VIEW employee_summary AS
SELECT id, first_name || ' ' || last_name AS full_name, salary
FROM employees;

CREATE TRIGGER employee_summary_insert
INSTEAD OF INSERT ON employee_summary
BEGIN
    INSERT INTO employees(first_name, last_name, salary)
    VALUES (
        substr(NEW.full_name, 1, instr(NEW.full_name, ' ') - 1),
        substr(NEW.full_name, instr(NEW.full_name, ' ') + 1),
        NEW.salary
    );
END;

INSERT INTO employee_summary(full_name, salary) VALUES ('Boris Petrov', 60000);
SELECT * FROM employees;

Die Anwendung spricht mit der View, als wäre sie eine Tabelle. Im Hintergrund kümmert sich der Trigger darum, den Wert sauber in first_name und last_name aufzuteilen.

SQLite Trigger anzeigen und löschen

Trigger werden – genau wie Tabellen und Indizes – in sqlite_master abgelegt:

CREATE TABLE notes (id INTEGER PRIMARY KEY, body TEXT);

CREATE TRIGGER touch_note
AFTER UPDATE ON notes
BEGIN
    SELECT 1; -- Platzhalter-Rumpf
END;

SELECT name, tbl_name, sql
FROM sqlite_master
WHERE type = 'trigger';

DROP TRIGGER IF EXISTS touch_note;

SELECT count(*) AS remaining
FROM sqlite_master
WHERE type = 'trigger';

DROP TRIGGER IF EXISTS name; ist die sichere Variante. Wenn du die zugehörige Tabelle löschst, verschwindet der Trigger automatisch mit – aufräumen musst du also nicht von Hand.

Stolpersteine, die du kennen solltest

Ein paar Dinge erwischen einen beim ersten Mal:

• Trigger feuern pro Zeile, nicht pro Statement. Ein UPDATE, das 1.000 Zeilen betrifft, löst den Trigger 1.000 Mal aus. Wenn der Trigger-Body selbst aufwendig ist, summiert sich das schnell.
• Trigger laufen innerhalb der umgebenden Transaktion. Rollt das äußere Statement zurück, werden auch die Schreibvorgänge des Triggers zurückgerollt. Meistens ist genau das gewollt – aber ein Trigger ist eben kein Notausgang für „bitte auf jeden Fall mitloggen".
• Rekursive Trigger sind standardmäßig aus. Ein Trigger, der dieselbe Tabelle verändert, ruft sich nicht selbst erneut auf, solange du nicht PRAGMA recursive_triggers = ON; setzt. Lass das aus, wenn du keinen konkreten Grund hast.
• Schreibzugriffe aus der Anwendung können Trigger nur umgehen, indem sie die Datenbank komplett umgehen. Solange jeder Write durch SQLite geht, läuft der Trigger. Auch ORMs, die per Raw-SQL batchen, lösen ihn aus.
• Verteile keine Geschäftslogik über viele Trigger. Vom Aufrufort aus sind sie unsichtbar – wer debuggen muss, „warum ist diese Zeile plötzlich da?", darf erst mal sqlite_master durchgreppen. Nimm sie für Querschnittsthemen (Audit-Logs, abgeleitete Spalten, beschreibbare Views) und halte den Rest in der Anwendungslogik.

Ein realistisches Beispiel: Audit-Log

Bringen wir die Patterns zusammen – jede Änderung an einer posts-Tabelle wird protokolliert:

CREATE TABLE posts (
    id INTEGER PRIMARY KEY,
    title TEXT NOT NULL,
    body TEXT,
    updated_at TEXT
);

CREATE TABLE post_audit (
    post_id INTEGER,
    action TEXT,
    old_title TEXT,
    new_title TEXT,
    at TEXT DEFAULT CURRENT_TIMESTAMP
);

CREATE TRIGGER posts_audit_update
AFTER UPDATE OF title, body ON posts
BEGIN
    UPDATE posts SET updated_at = CURRENT_TIMESTAMP WHERE id = NEW.id;
    INSERT INTO post_audit(post_id, action, old_title, new_title)
    VALUES (NEW.id, 'update', OLD.title, NEW.title);
END;

INSERT INTO posts(title, body) VALUES ('Entwurf', 'erste Fassung');
UPDATE posts SET title = 'Veröffentlicht' WHERE id = 1;
SELECT id, title, updated_at FROM posts;
SELECT * FROM post_audit;

Ein einziger Trigger hält updated_at zuverlässig aktuell und schreibt an einer zentralen Stelle einen Audit-Eintrag. Der Anwendungscode, der das UPDATE absetzt, muss von beidem nichts wissen.

Weiter geht's: JSON-Unterstützung

Trigger kümmern sich um die Automatisierung rund um Zeilenereignisse. Der nächste fortgeschrittene SQLite-Baustein dreht sich darum, was du innerhalb einer Zeile ablegen kannst — nämlich JSON. SQLite bringt einen kompletten Satz an JSON-Funktionen mit, mit denen du strukturierte Daten direkt in SQL abfragen und verändern kannst. Genau darum geht's auf der nächsten Seite.