如果有副作用，那就是故意造成的问题。 在一些数据库系统中，没有其他方法可以设置一个自增字段，即主键ID字段。

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

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

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

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

触发器的主要问题是

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

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

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

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

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

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

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

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

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

大多数情况下,是的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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...

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

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.

触发器的概念并不邪恶，限制触发器的嵌套是邪恶的。

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

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

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

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

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

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

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

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

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

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

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