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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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