Sie sind nicht dasselbe, aber sie sind nicht unähnlich.
In beiden Fällen lässt sich der Mechanismus ungefähr wie folgt beschreiben:
- Einige Codeblöcke erklären "Interesse" für Zustandsänderungen.
- Ihre Bewerbung bewirkt eine Veränderung.
- Das System führt den Codeblock als Reaktion auf die Änderung aus.
Vielleicht ist ein Datenbank-Trigger eher eine Callback-Funktion, die Interesse an einem bestimmten Ereignis angemeldet hat.
Hier eine Analogie: Das Ereignis ist ein Gummiball, den man wirft. Der Auslöser ist ein Hund, der dem geworfenen Ball hinterherjagt.
Wenn Sie einen anderen Unterschied im Kopf haben, der es "gefährlich" macht (Anmerkung: OP hat diese Wortwahl aus der Frage herausgenommen), Auslöser und Ereignisse zu vergleichen, können Sie beschreiben, was Sie meinen.
Auslöser sind eine Möglichkeit, zwischen sich wiederholende Logik synchron in den Ausführungsstrang einzufügen (d. h. Synchronität). Ereignisse sind ein Mittel zur Logik auf einen späteren Zeitpunkt zu verschieben (d.h. realisieren Asynchronität).
Okay, ich verstehe jetzt besser, was Sie meinen. Aber ich denke, es ist in gewisser Weise abhängig von der Implementierung. Ich würde nicht davon ausgehen, dass ein Event-Handler sich selbst deregistrieren muss; das hängt von dem System ab, das Sie verwenden. Ein UNIX-Signalhandler muss zum Beispiel verhindern, dass er ein neues Signal abfängt, während er bereits eines bearbeitet. Ein Java-Servlet innerhalb eines Tomcat-Containers sollte hingegen thread-sicher sein, da es von mehreren Threads gleichzeitig aufgerufen werden kann. Es sind beides Ereignisbehandler, aber unterschiedlicher Art.
Ereignisbehandler können synchron oder asynchron sein. Kann ein Handler in einem Veröffentlichungs-/Abonnement-System Nachrichten lesen, die kürzlich, aber vor der Registrierung des Handlers veröffentlicht wurden? Oder nur Nachrichten, die gleichzeitig veröffentlicht wurden?
Es gibt einen weiteren wichtigen Grund, Trigger anders zu behandeln als Event-Handler: Ich empfehle häufig gegen in einem Trigger etwas zu tun, das den Zustand außerhalb der Datenbank beeinflusst.
Zum Beispiel ist das Senden einer E-Mail, das Schreiben in eine Datei, das Senden an einen Webdienst oder das Forken eines Prozesses innerhalb eines Triggers unangebracht. Aus keinem anderen Grund als dem, dass die Transaktion, die den Trigger ausgelöst hat, rückgängig gemacht werden kann, aber Sie können diese externen Effekte nicht rückgängig machen. Möglicherweise verwenden Sie nicht einmal explizite Transaktionen, aber nehmen wir an, Sie senden eine E-Mail in einem BEFORE-Trigger, aber der Vorgang schlägt aufgrund einer NOT NULL-Beschränkung oder ähnlichem fehl.
Stattdessen sollten alle diese Arbeiten durch Code in der eigenen Anwendung erledigt werden, nach man hat bestätigt, dass die SQL-Operation erfolgreich war und die Transaktion bestätigt wurde.
Es ist schade, dass immer wieder versucht wird, unangemessene Arbeiten innerhalb eines Auslösers durchzuführen. Es gibt leitende Entwickler bei MySQL, die UDFs zum Lesen und Schreiben von Daten in Memcached fördern. Wow - ich habe gerade bemerkt, dass diese wurde in das Produkt MySQL 6.0 aufgenommen !! Schockierend!
Hier also ein weiterer Versuch einer Analogie, bei dem Auslöser und Ereignisse mit dem Ablauf eines Strafprozesses verglichen werden:
- Ein BEFORE-Auslöser ist eine Anschuldigung.
- Ein AFTER-Auslöser ist eine Anklageschrift.
- COMMIT ist eine Verurteilung nach einem Schuldspruch.
- ROLLBACK ist ein Freispruch nach einem Unschuldsurteil.
Sie wollen den Täter erst ins Gefängnis bringen, wenn er verurteilt ist.
- Ein EVENT hingegen ist die Straftat selbst.
