对于另一个问题，我遇到了一个似乎偶尔出现在 SO 的误解。一些提问者似乎认为触发器之于数据库就像事件之于 OOP 一样。
有没有人有一个很好的类比来解释为什么这是一个有缺陷的比较，以及误用它的后果？
编辑:
Bill K. 正确地击中了它，但也许没有看到事件和让我印象深刻的回调函数之间的关键区别的重要性，无论如何。触发器实际上会导致代码在每次事件发生时执行；回调仅在为事件注册时发生(对于绝大多数事件而言并非如此)；即便如此，在大多数情况下，回调的第一个 Action 是注销自身(或者至少回调包含一个限定退出，因此它只执行一次。)
如果你写一个触发器，它会在每次事件发生时都执行，因为没有办法注册或取消注册到代码段。
触发器是一种将重复逻辑同步插入执行线程(即同步性)的方法。事件是一种将逻辑推迟到以后的方法(即实现异步)。
这两种情况都有异常(exception)和缓解措施，但触发器和回调的基本模式在意图和实现上大多是相反的。通常，这种区别似乎并没有完全体现出来。(恕我直言，YMMV)。 :D
最佳答案
它们不是一回事，但它们并非无关。
在这两种情况下，机制可以大致描述如下:
也许数据库触发器更像是一个对特定事件感兴趣的回调函数。
这是一个类比:事件是你扔的一个橡皮球。扳机是一只追逐 throw 球的狗。
如果您想到的其他一些差异使其“危险”(注意:OP 已经编辑了这个词的选择，这是不可能的)来比较触发器和事件，您可以描述您的意思。
Triggers are a way to interpose repeating logic synchronously into the thread of execution (i.e. synchronicity). Events are a means to defer logic until later (i.e. implement asynchronicity).
好的，我明白你的意思更清楚了。但我认为它在某些方面受制于实现。我不认为事件处理程序必须自行注销。这取决于您使用的系统。例如，一个 UNIX 信号处理程序必须防止自己在处理一个新信号时捕获一个新信号。但是 Tomcat 容器中的 Java servlet 应该是线程安全的，因为它可以被多个线程同时调用。它们都是不同类型的事件处理程序。
事件处理程序可以是同步的或异步的。发布/订阅系统中的处理程序能否读取最近发布但在处理程序注册其兴趣之前发布的消息？还是只有同时发布的消息？
将触发器视为与事件处理程序不同的另一个重要原因是:我经常建议不要在触发器中执行任何影响数据库外部状态的操作。
例如，发送电子邮件、写入文件、发布到 Web 服务或 fork 进程在触发器中是不合适的。如果除了产生触发器的事务之外没有其他原因，可能会回滚，但您不能回滚那些外部影响。您甚至可能没有使用显式事务，但假设您在 BEFORE 触发器中发送电子邮件，但由于 NOT NULL 约束或其他原因，操作失败。
相反，在确认 SQL 操作成功并提交事务之后，所有这些工作都应该由应用程序中的代码完成。
人们一直试图在触发器内做不适当的工作，这太糟糕了。 MySQL 有高级开发人员推广 UDF 在 memcached 中读写数据。哇——我刚刚注意到这些有made it into the MySQL 6.0 product !!震惊!
因此，这是另一个类比的尝试，将触发器和事件与刑事审判的过程进行比较:
你只想在犯罪者被定罪后把他们关进 jail 。
关于events - 我需要一个类比 : Triggers and Events，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/494774/