这个答案特别适用于SQL Server。(虽然它也可能适用于其他rdbms，我不知道。我更愿意在这里给出一个答案，但这是一个抄袭。)

到目前为止，所有答案中都没有提到的一个方面是安全性。因为在默认情况下，触发器是在执行触发触发器的语句的用户的上下文中执行的，这可能会导致安全威胁，除非检查所有触发器。

在BOL中“管理触发器安全性”标题下给出的示例是一个用户创建了一个包含代码GRANT CONTROL SERVER TO JohnDoe的触发器;以便升级自己的权限。

触发器的主要问题是

它们是完全全局的——无论表活动的上下文是什么，它们都适用; 他们是隐秘的;你很容易忘记他们的存在，直到他们用意想不到的(非常神秘的)后果伤害了你。

这只是意味着它们需要在适当的情况下谨慎使用;在我的经验中，这仅限于关系完整性问题(有时比您可以声明的粒度更细);而且通常不是出于商业或交易目的。YMMV。

我知道有些开发人员认为触发器应该总是用于实现他们想要的功能的最直接方式，而有些开发人员则永远不会这样做。这几乎就像是两个阵营之间的教条。

然而，我个人完全同意MarkR -你可以(几乎)总是编写与触发器功能相当的代码，这将更清晰，因此更容易维护。

不，其实这是个好主意。如果你的特定触发器有问题，那么你做得不对，但这通常意味着你的实现有问题，而不是触发器本身的概念:-)。

我们经常使用触发器，因为它将特定于dbms的活动置于其所属数据库的控制之下。DBMS的用户不应该担心这类事情。数据的完整性取决于数据库本身，而不是使用它的应用程序或用户。如果数据库中没有约束、触发器和其他特性，执行规则的任务就留给了应用程序，只需要一个流氓或有bug的应用程序/用户就可以破坏数据。

例如，如果没有触发器，像自动生成列这样奇妙的东西就不存在了，在选择它们时，您必须在每行上处理一个函数。这可能会降低DBMS的性能，在插入/更新时创建自动生成的列要好得多，因为只有在插入/更新时才会更改列。

此外，缺乏触发器将阻止在DBMS中强制执行数据规则，例如预先触发器，以确保列具有特定的格式。注意，这与数据完整性规则不同，后者通常只是外键查找。

不是邪恶的。它们实际上简化了事情

1.记录/审计对记录甚至数据库模式的更改

您可以在ALTER TABLE上设置一个触发器，用于回滚生产环境中的更改。这应该可以防止任何意外的表修改。

2.跨多个数据库强制执行引用完整性(主键/外键关系等)

他们绝对不是邪恶的。我发现在重构数据库模式、重命名列或将列分成两列或相反(例如:姓名/姓氏情况)并协助转换时，触发器非常宝贵。

它们对于审计也非常有用。