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

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

触发器是非常强大和有用的，在许多情况下，触发器是解决问题的最佳方案。

它们也是一个非常好的“黑客”工具。通常情况下，您不能立即控制代码和数据库。如果您必须等待2个月才能看到代码的下一个主要版本，但您可以立即将补丁应用到数据库，然后您可以在表上放置触发器来执行一些额外的功能。然后，当代码可能发布时，如果需要，您可以用相同功能的编码版本替换此触发器。

在一天结束的时候，如果你不知道它在做什么，一切都是“邪恶的”。决定触发器是因为开发者不理解它们，这就像争论汽车是邪恶的，因为有些人不会开车……

说他们是邪恶的是一种夸张，但他们可以引起网格。当一个触发器触发其他触发器时，情况就变得非常复杂了。让我们假设它们很麻烦:http://www.oracle.com/technology/oramag/oracle/08-sep/o58asktom.html

由于多并发问题，在Oracle中使用触发器执行业务逻辑比看起来要难。在其他会话提交之前，您不会在另一个会话中看到更改。

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

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

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

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

在高层次上，触发器有两个用例1

1)让事情“自动地”发生。在这种情况下，触发器会产生副作用，它们会以超出预期的方式改变数据，因为执行了(原语)操作符insert、update或delete并导致触发器触发。

这里的普遍共识是，触发器确实有害。因为它们改变了INSERT、UPDATE或DELETE语句的众所周知的语义。更改这三个原语SQL操作符的语义将会对其他开发人员造成不利影响，这些开发人员将来需要对数据库表进行操作，而这些表在使用SQL原语操作时不再以预期的方式运行。

2)执行数据完整性规则，而不是我们可以声明式处理的规则(使用CHECK, PRIMARY KEY, UNIQUE KEY和外键)。在这个用例中，所有触发器所做的就是查询(SELECT)数据，以验证由INSERT/UPDATE/DELETE所做的更改是否被允许。就像声明性约束对我们的作用一样。只有在这种情况下，我们(开发人员)才编写了实施程序。

对于后一种用例，使用触发器是无害的。

我的博客地址是:http://harmfultriggers.blogspot.com

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

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