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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

大多数情况下,是的。

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

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

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