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

大多数情况下,是的。

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

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

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

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

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

触发器的主要问题是

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

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

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

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

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

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

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

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

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

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