根据我的经验,它们不是一个好主意,因为它们可能会导致令人惊讶的副作用,并且很难调试(特别是当一个触发器触发另一个触发器时)。通常情况下,开发人员甚至不会考虑是否存在触发因素。
另一方面,如果每次在数据库中创建新FOO时都必须执行逻辑,那么将其放在FOO表上的插入触发器可能是最安全的地方。
我们唯一使用触发器的时候是非常简单的事情,比如设置一行的修改日期字段。
我正在努力弄清楚触发器是否有必要,并感谢任何建议。如果它们是必要的,在实施它们时要考虑的最重要的问题是什么?
根据我的经验,它们不是一个好主意,因为它们可能会导致令人惊讶的副作用,并且很难调试(特别是当一个触发器触发另一个触发器时)。通常情况下,开发人员甚至不会考虑是否存在触发因素。
另一方面,如果每次在数据库中创建新FOO时都必须执行逻辑,那么将其放在FOO表上的插入触发器可能是最安全的地方。
我们唯一使用触发器的时候是非常简单的事情,比如设置一行的修改日期字段。
我正在努力弄清楚触发器是否有必要,并感谢任何建议。如果它们是必要的,在实施它们时要考虑的最重要的问题是什么?
当前回答
在高层次上,触发器有两个用例1
1)让事情“自动地”发生。在这种情况下,触发器会产生副作用,它们会以超出预期的方式改变数据,因为执行了(原语)操作符insert、update或delete并导致触发器触发。
这里的普遍共识是,触发器确实有害。因为它们改变了INSERT、UPDATE或DELETE语句的众所周知的语义。更改这三个原语SQL操作符的语义将会对其他开发人员造成不利影响,这些开发人员将来需要对数据库表进行操作,而这些表在使用SQL原语操作时不再以预期的方式运行。
2)执行数据完整性规则,而不是我们可以声明式处理的规则(使用CHECK, PRIMARY KEY, UNIQUE KEY和外键)。在这个用例中,所有触发器所做的就是查询(SELECT)数据,以验证由INSERT/UPDATE/DELETE所做的更改是否被允许。就像声明性约束对我们的作用一样。只有在这种情况下,我们(开发人员)才编写了实施程序。
对于后一种用例,使用触发器是无害的。
我的博客地址是:http://harmfultriggers.blogspot.com
其他回答
如果使用得当,触发器是一个很好的工具。特别是对于审计变更、填充汇总表等。
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...
所以,如果你正确地看待你所做的事情,它们是很棒的。如果是一些非常简单的事情,如审核、总结、自动排序等,那就没问题。只需要记住表的增长速度以及触发器将如何影响性能。
触发器的主要问题是
它们是完全全局的——无论表活动的上下文是什么,它们都适用; 他们是隐秘的;你很容易忘记他们的存在,直到他们用意想不到的(非常神秘的)后果伤害了你。
这只是意味着它们需要在适当的情况下谨慎使用;在我的经验中,这仅限于关系完整性问题(有时比您可以声明的粒度更细);而且通常不是出于商业或交易目的。YMMV。
说他们是邪恶的是一种夸张,但他们可以引起网格。当一个触发器触发其他触发器时,情况就变得非常复杂了。让我们假设它们很麻烦:http://www.oracle.com/technology/oramag/oracle/08-sep/o58asktom.html
由于多并发问题,在Oracle中使用触发器执行业务逻辑比看起来要难。在其他会话提交之前,您不会在另一个会话中看到更改。
不,其实这是个好主意。如果你的特定触发器有问题,那么你做得不对,但这通常意味着你的实现有问题,而不是触发器本身的概念:-)。
我们经常使用触发器,因为它将特定于dbms的活动置于其所属数据库的控制之下。DBMS的用户不应该担心这类事情。数据的完整性取决于数据库本身,而不是使用它的应用程序或用户。如果数据库中没有约束、触发器和其他特性,执行规则的任务就留给了应用程序,只需要一个流氓或有bug的应用程序/用户就可以破坏数据。
例如,如果没有触发器,像自动生成列这样奇妙的东西就不存在了,在选择它们时,您必须在每行上处理一个函数。这可能会降低DBMS的性能,在插入/更新时创建自动生成的列要好得多,因为只有在插入/更新时才会更改列。
此外,缺乏触发器将阻止在DBMS中强制执行数据规则,例如预先触发器,以确保列具有特定的格式。注意,这与数据完整性规则不同,后者通常只是外键查找。
我知道有些开发人员认为触发器应该总是用于实现他们想要的功能的最直接方式,而有些开发人员则永远不会这样做。这几乎就像是两个阵营之间的教条。
然而,我个人完全同意MarkR -你可以(几乎)总是编写与触发器功能相当的代码,这将更清晰,因此更容易维护。