Was sind Datenbank-Trigger (BeforeSave und AfterSave)?

Ein Datenbank-Trigger ist ein Code-Hook, der bei Datenereignissen automatisch läuft – vor dem Speichern zum Validieren, danach zum Reagieren. Die Idee hat zwei Abstammungslinien mit einem gemeinsamen Prinzip: den klassischen SQL-Trigger, prozeduralen Code, der in der Datenbank-Engine wohnt, und den modernen Hook auf Anwendungsebene – beforeSave, afterSave, beforeDelete – JavaScript, das pro Klasse im Backend registriert wird. Beide kodieren dasselbe Versprechen: Die Regel feuert bei jedem Schreibvorgang, gleich welcher Client, welches SDK oder welches Skript ihn ausgeführt hat – und genau das kann clientseitige Validierung nie versprechen.

Das Wichtigste im Überblick

Das Hook-Modell in der Praxis

Eine Validierungsregel und ihre Durchsetzung, von beiden Enden aus gesehen – der Server definiert sie einmal, und jeder Client überall erbt sie:

// JavaScript — Cloud Code (cloud/main.js)
// beforeSave: validate + normalize — can still change or ABORT the write
Parse.Cloud.beforeSave('Review', (req) => {
  const stars = req.object.get('stars');
  if (stars < 1 || stars > 5) throw 'Stars must be between 1 and 5';
  const comment = req.object.get('comment');
  if (comment && comment.length > 500) {
    req.object.set('comment', comment.slice(0, 497) + '…');
  }
});

// afterSave: side effects — the write already happened; be idempotent
Parse.Cloud.afterSave('Review', async (req) => {
  if (req.object.existed()) return; // count only NEW reviews, once
  await updateAverageStars(req.object.get('movie'));
});

// Flutter / Dart — Back4app Flutter SDK
// The hook fires for EVERY write path — this client included
final review = ParseObject('Review')
  ..set('movie', 'Arrival')
  ..set('stars', 9); // invalid — no client-side check needed
final response = await review.save();
print(response.error?.message); // "Stars must be between 1 and 5"
// The beforeSave hook rejected it server-side. A forged REST call,
// another SDK, an admin script — same rule, same rejection.

// iOS / Swift — Back4app Swift SDK
// The hook fires for EVERY write path — this client included
var review = Review()
review.movie = "Arrival"
review.stars = 9 // invalid — no client-side check needed
do {
    _ = try await review.save()
} catch {
    print(error.localizedDescription) // "Stars must be between 1 and 5"
}
// The beforeSave hook rejected it server-side. A forged REST call,
// another SDK, an admin script — same rule, same rejection.

// Android / Kotlin — Back4app Android SDK
// The hook fires for EVERY write path — this client included
val review = ParseObject("Review")
review.put("movie", "Arrival")
review.put("stars", 9) // invalid — no client-side check needed
try {
    review.save()
} catch (e: ParseException) {
    println(e.message) // "Stars must be between 1 and 5"
}
// The beforeSave hook rejected it server-side. A forged REST call,
// another SDK, an admin script — same rule, same rejection.

Die vollständige Hook-Familie überträgt dieselbe Form auf den gesamten Datenlebenszyklus: beforeSave/afterSave, beforeDelete (das Löschen eines Albums verhindern, das noch Fotos enthält) und afterDelete (seine Kinder aufräumen), dazu beforeFind/afterFind, um Abfragen umzuschreiben und Felder aus Ergebnissen zu entfernen – CRUD, eingepackt.

Die klassische Form: SQL-Trigger

CREATE TRIGGER audit_price_change
AFTER UPDATE ON products
FOR EACH ROW                              -- Zeilenebene: feuert pro betroffener Zeile
WHEN (OLD.price IS DISTINCT FROM NEW.price)
EXECUTE FUNCTION log_price_change();      -- OLD und NEW halten beide Versionen

Die Taxonomie, die alle Datenbanken teilen, gemäß den Referenzen von PostgreSQL und MySQL: der Zeitpunkt – BEFORE (darf NEW ändern oder abbrechen), AFTER (reagiert auf die geschriebene Zeile), INSTEAD OF (ersetzt die Operation, vor allem bei Views); das Ereignis – Insert, Update, Delete; die Granularität – Zeilenebene gegenüber Anweisungsebene (ein Update über 10 Zeilen feuert einen Zeilen-Trigger 10-mal, einen Anweisungs-Trigger einmal). Zwei Semantiken zum Einprägen: SQL-Trigger laufen in derselben Transaktion wie der Schreibvorgang – scheitert der Trigger, wird die gesamte Operation zurückgerollt – und AFTER-Trigger feuern nur für Schreibvorgänge, die tatsächlich erfolgreich waren.

Before vs. after: die Wahl richtet sich nach der Aufgabe

Die Folgerungen, die kein Erklärtext ausspricht: Eine Nebenwirkung in einem Before-Hook ist ein Bug per Konstruktion (die E-Mail geht raus, dann scheitert der Speichervorgang), und ein nicht idempotenter After-Hook ist ein doppelter Zähler, der auf seinen Wiederholungsversuch wartet. In Hook-Systemen wie dem von Back4app läuft afterSave zu Ende, nachdem der Client seine Antwort bereits erhalten hat – Reaktionen sind von Natur aus asynchron, ihre Fehler müssen also verkraftbar und protokolliert sein.

Hooks vs. SQL-Trigger

Die letzte Zeile ist die ehrliche Symmetrie: Die Garantie jeder Form endet an ihrer Schicht. Ein SQL-Trigger erwischt selbst eine wildgewordene psql-Sitzung, verbirgt die Logik aber vor dem Anwendungswerkzeug; ein Hook auf API-Ebene bindet jeden Client-Pfad durch das Backend, nicht aber den direkten Datenbankzugriff – weshalb Plattformen, denen das API-Gateway gehört (aller Verkehr fließt hindurch), in der Praxis das Beste aus beiden Welten bekommen. Die Fußnote zu ORMs gehört ebenfalls hierher: ORM-Hooks feuern nur über den ORM – Massenoperationen und rohes SQL laufen einfach daran vorbei.

Die Fallstricke, ehrlich benannt

Versteckte Logik ist der Klassiker: Ein Entwickler debuggt stundenlang seinen eigenen Code, während ein Trigger im Stillen Werte umschreibt – Trigger sind an der Aufrufstelle unsichtbar, dokumentieren Sie sie also und halten Sie ihre Zahl klein. Endlosschleifen: Ein Trigger, der in seine eigene Tabelle schreibt (oder ein afterSave, das sein eigenes Objekt speichert), löst sich selbst erneut aus; prüfen Sie, was sich geändert hat, und geben Sie der Rekursion eine Abbruchbedingung, bevor sie selbst eine findet. Synchrone Kosten: Before-Hooks sitzen in der Latenz jedes Schreibvorgangs – ein Hook von 200 ms macht jeden Speichervorgang 200 ms langsamer, und Massenschreibvorgänge multiplizieren die Auslösungen auf Zeilenebene mit der Zeilenzahl. Kaskadenketten: Trigger, die Trigger auslösen, die Trigger auslösen, machen aus einem Insert ein archäologisches Projekt. Die Dachregel aus Jahrzehnten der Praxis: Trigger setzen Regeln durch; sobald einer anfängt, einen Ablauf zu orchestrieren, verlagern Sie den Ablauf in Funktionen oder Jobs und lassen den Trigger nur noch in die Queue einreihen.

Typische Anwendungsfälle

• Validierung, die jeder Client befolgt – die Regel “Sterne zwischen 1 und 5”, durchgesetzt gegen gefälschte Anfragen ebenso wie gegen künftige SDKs.
• Audit-Spuren – wer hat wann was geändert, geschrieben vom Ereignis selbst statt von kooperativen Clients.
• Denormalisierte Zähler und berechnete Felder – Durchschnitte, Anzahlen und suchfreundliche Duplikate, zum Schreibzeitpunkt aktuell gehalten.
• Integrität in Kaskaden – Löschvorgänge verweigern, solange Kinder existieren, oder die Kinder danach aufräumen.
• Reaktive Nebenwirkungen – ein afterSave, das eine Push-Benachrichtigung oder einen ausgehenden Webhook auslöst: aus dem Datenbankereignis wird ein Integrationsereignis.

Welcher Hook wofür? Entscheidungsmatrix

Grenzen und Trade-offs

• Unsichtbarkeit ist der Preis der Automatik. Logik, die niemand aufruft, ist Logik, an die sich niemand erinnert; Benennung, Dokumentation und Code-Review halten die Magie prüfbar.
• Hooks reichen nur so weit wie ihre Schicht. API-Hooks übersehen direkte Schreibvorgänge in die Datenbank; SQL-Trigger übersehen nichts, verstecken sich aber vor Ihrem Werkzeug – wissen Sie, welchen blinden Fleck Sie gewählt haben.
• Die Schreiblatenz ist das Budget. Jeder Before-Hook zehrt davon; messen Sie Hooks so, wie Sie Abfragen messen.
• After-Hooks sind letztendlich konsistent. Zähler hinken Millisekunden hinterher und können doppelt feuern – gestalten Sie Lesevorgänge (und Wiederholungsversuche) entsprechend.
• Trigger ersetzen keine Constraints. Eindeutige Indizes, Fremdschlüssel und ACLs greifen früher und billiger; Trigger übernehmen dort, wo deklarative Regeln aufhören.

Trigger mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Trigger sind hier die Datenereignis-Familie von Cloud Code: Registrieren Sie Parse.Cloud.beforeSave('Review', …) einmal – die Code-Tabs zeigen das vollständige Muster – und die Regel bindet jeden Schreibvorgang, der über REST, GraphQL, ein beliebiges SDK oder das Dashboard hereinkommt, weil das API-Gateway der einzige Weg zu den Daten ist. Hooks erhalten reichhaltigen Kontext (request.object, request.original, request.user, Master-Key-Status), sodass die Validierung für Administratoren abweichen kann, beforeFind Abfragen zusätzlich zu den ACLs pro Nutzer eingrenzen kann und After-Hooks das gesamte JavaScript-Ökosystem für die Reaktionen zur Verfügung haben, die SQL-Trigger nicht erreichen – Push-Benachrichtigungen, ausgehende Webhooks, Einreihungen in Job-Queues. Mit Ihrem Code deployt, in git versioniert, testbar wie jede Funktion: die Garantie des Triggers, ohne seine Archäologie.