触发器的主要问题是

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

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

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

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

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

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

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

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

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

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

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

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

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