Ich bin gespannt, ob ich mich auf eine bestimmte Reihenfolge der Validierung von NOT NULL, FOREIGN KEY, UNIQUE, CHECK constraints und BEFORE triggern verlassen kann.
Aus Erfahrung weiß ich, dass MySQL zuerst NOT NULL prüft, dann BEFORE trigger startet und dann UNIQUE constraints prüft. Oracle überprüft NOT NULL nach dem BEFORE -Auslöser (ich glaube, SQL Server macht das gleiche, aber erinnere mich nicht). Sagt der Standard etwas über die Bestellung oder ist es vollständig an DB-Anbieter?
Dieses bestimmte Verhalten scheint ein Fehler in MySQL zu sein und betrifft nur BEFORE INSERT Trigger , während BEFORE UPDATE Trigger sich korrekt verhalten.
Der Standard (wie in Fragekommentare verlinkt) gibt es sicherlich nicht explizit aus, aber es ist definitiv impliziert:
Für jede Zustandsänderung SCi, j in TECi, werden die von SCi aktivierten BEFORE-Trigger vor jedem von ihnen ausgeführt auslösende Ereignisse werden wirksam. Wenn diese auslösenden Ereignisse wirksam werden, werden alle AFTER-Trigger aktiviert durch Die Statusänderungen von TECi werden ausgeführt.
Ein NOT NULL Fehler sollte Teil eines INSERT oder UPDATE sein (d. h. das auslösende Ereignis). Der Standard sollte dies nicht spezifizieren müssen. Es gibt absolut keinen Punkt, um Einschränkungen für eine Reihe von Änderungen präventiv zu prüfen, was nicht endgültig ist, weil Ihr BEFORE -Trigger sowohl Fehler auflösen als auch neue einführen kann .
ZUSAMMENFASSUNG: Es ist wirklich nicht Sache des DB-Anbieters, da die Überprüfung von Constraints nach einem Vorher-Trigger immer erforderlich ist.
Tags und Links sql sql-standards