根据我的经验,它们不是一个好主意,因为它们可能会导致令人惊讶的副作用,并且很难调试(特别是当一个触发器触发另一个触发器时)。通常情况下,开发人员甚至不会考虑是否存在触发因素。

另一方面,如果每次在数据库中创建新FOO时都必须执行逻辑,那么将其放在FOO表上的插入触发器可能是最安全的地方。

我们唯一使用触发器的时候是非常简单的事情,比如设置一行的修改日期字段。

我正在努力弄清楚触发器是否有必要,并感谢任何建议。如果它们是必要的,在实施它们时要考虑的最重要的问题是什么?


当前回答

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

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

其他回答

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

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

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

如果使用得当,触发器是一个很好的工具。特别是对于审计变更、填充汇总表等。

Now they can be "evil" if you end up in "trigger hell" with one trigger that kicks off other triggers. I once worked on a COTS product where they had what they called "flex triggers." These triggers were stored in a table as dynamic sql stings are were compiled every time they were executed. Compiled triggers would do a look up and see if that table had any flex triggers to run and then compile and run the "flex" trigger. In theory this sounded like a really cool idea because the product was easily customized but the reality was the database pretty much exploded due to all the compiles it had to do...

所以,如果你正确地看待你所做的事情,它们是很棒的。如果是一些非常简单的事情,如审核、总结、自动排序等,那就没问题。只需要记住表的增长速度以及触发器将如何影响性能。

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

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

触发器的主要问题是

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

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