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

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

工具从来都不是邪恶的。 这些工具的应用可能是邪恶的。

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

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

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

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

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

我同意。触发器的问题在于人，而不是触发器。尽管要看得更多，要考虑得更多，并且增加了编码员正确检查内容的责任，但我们不会为了简化工作而放弃索引。(糟糕的索引和糟糕的触发器一样糟糕)

触发器的重要性(在我看来)是…… -任何系统都应该始终处于有效状态 执行这种有效状态的代码应该集中(而不是写在每个SP中)

从维护的角度来看，触发器对于有竞争力的程序员和初级/业余程序员的问题非常有用。然而，这些人需要学习和成长。

我想这取决于你的工作环境。你有值得信赖的人吗?他们学习能力强，做事有条理?如果不是，你似乎有两个选择: -接受你不得不失去功能来补偿的事实 -接受你需要不同的人或更好的培训和管理

这些话听起来很刺耳，我想的确如此。但在我看来，这是基本事实……

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

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

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