触发器有它们的用途——日志记录/审计和维护“最后修改”日期是两个非常好的用途，在之前的回复中已经提到过。

然而，优秀设计的核心原则之一是业务规则/业务逻辑/无论你想称呼它什么，都应该集中在一个地方。将一些逻辑放在数据库中(通过触发器或存储过程)，将一些逻辑放在应用程序中违反了这一原则。在两个地方复制逻辑更糟糕，因为它们总是会彼此不同步。

还有一个已经提到过的“最小意外原则”问题。

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

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

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

我认为它们可以是邪恶的，但只能和其他正在开发的东西一样邪恶。

虽然我并没有太多使用它们的经验，但我在最近的一个项目中使用了它们，这让我得出了这个结论。我遇到的问题是，它们可能导致业务逻辑在两个位置结束，一个代码库和一个数据库。

我认为这与使用scprocs类似。您经常会遇到一些开发人员，他们非常擅长将业务逻辑写入SQL到数据库中，而那些不擅长的人将业务逻辑放在其他地方。

所以我的经验法则是看看你项目的结构是什么。如果在数据库中存储业务逻辑似乎是可行的，那么使用触发器可能是有用的。

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

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

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

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

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

I think triggers are not only not evil, but necessary to good database design. Application programmers think that databases are only affected by their application. They are often wrong. If data integrity is to be maintained no matter where the data change came from, triggers are a requirement and it is foolish to avoid them because some programmers are too ethnocentric to consider that something other than their prized application may be affecting things. It isn't hard to design or test or troubleshoot a trigger if you are a competent database developer. Nor it is difficult to determine that a trigger is causing an unexpected result if it occurs to you (as it does to me) to look there. If I get an error saying a table that I'm not referencing in my sp has an FK error, I know without even thinking about it that trigger is causing the problem and so should any competent database developer. Putting business rules only in the application is the number one cause I have found of bad data as others have no idea that rule even exists and violate it in their processes. Data-centric rules belong in the database and triggers are key to enforcing the more complex ones.

大多数情况下,是的。

扳机的困难在于它是“在你背后”做事情的;维护应用程序的开发人员很容易没有意识到它的存在，甚至在没有注意到的情况下做了一些更改，把事情搞砸了。

它增加了一层复杂性，增加了维护工作。

不使用触发器，存储过程/例程通常可以做同样的事情，但以一种清晰和可维护的方式-调用存储例程意味着开发人员可以查看其源代码并确切地了解发生了什么。