不，他们不邪恶——他们只是被误解了:- d

触发器有一个有效的用途，但往往是作为一个复古黑客，最终使事情变得更糟。

如果您将DB作为应用程序的一部分进行开发，那么逻辑应该始终存在于进行调用的代码或scprocs中。触发器只会导致稍后的调试痛苦。

如果您了解锁、死锁以及DB如何访问磁盘上的文件，那么以正确的方式使用触发器(例如审计或归档直接DB访问)将非常有价值。

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

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

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

事实上，触发器经常被滥用。事实上，在大多数情况下，你甚至不需要它们。但这并不意味着它们就一定是坏事。

我想到的一个触发器很有用的场景是，当你有一个遗留应用程序，你没有源代码，也没有办法改变它。

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

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

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

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

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

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

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

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

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

如果使用得当，触发器是一个很好的工具。特别是对于审计变更、填充汇总表等。

Now they can be "evil" if you end up in "trigger hell" with one trigger that kicks off other triggers. I once worked on a COTS product where they had what they called "flex triggers." These triggers were stored in a table as dynamic sql stings are were compiled every time they were executed. Compiled triggers would do a look up and see if that table had any flex triggers to run and then compile and run the "flex" trigger. In theory this sounded like a really cool idea because the product was easily customized but the reality was the database pretty much exploded due to all the compiles it had to do...

所以，如果你正确地看待你所做的事情，它们是很棒的。如果是一些非常简单的事情，如审核、总结、自动排序等，那就没问题。只需要记住表的增长速度以及触发器将如何影响性能。