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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

触发器的主要问题是

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

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