根据我的经验,它们不是一个好主意,因为它们可能会导致令人惊讶的副作用,并且很难调试(特别是当一个触发器触发另一个触发器时)。通常情况下,开发人员甚至不会考虑是否存在触发因素。
另一方面,如果每次在数据库中创建新FOO时都必须执行逻辑,那么将其放在FOO表上的插入触发器可能是最安全的地方。
我们唯一使用触发器的时候是非常简单的事情,比如设置一行的修改日期字段。
我正在努力弄清楚触发器是否有必要,并感谢任何建议。如果它们是必要的,在实施它们时要考虑的最重要的问题是什么?
根据我的经验,它们不是一个好主意,因为它们可能会导致令人惊讶的副作用,并且很难调试(特别是当一个触发器触发另一个触发器时)。通常情况下,开发人员甚至不会考虑是否存在触发因素。
另一方面,如果每次在数据库中创建新FOO时都必须执行逻辑,那么将其放在FOO表上的插入触发器可能是最安全的地方。
我们唯一使用触发器的时候是非常简单的事情,比如设置一行的修改日期字段。
我正在努力弄清楚触发器是否有必要,并感谢任何建议。如果它们是必要的,在实施它们时要考虑的最重要的问题是什么?
当前回答
触发器的主要问题是
它们是完全全局的——无论表活动的上下文是什么,它们都适用; 他们是隐秘的;你很容易忘记他们的存在,直到他们用意想不到的(非常神秘的)后果伤害了你。
这只是意味着它们需要在适当的情况下谨慎使用;在我的经验中,这仅限于关系完整性问题(有时比您可以声明的粒度更细);而且通常不是出于商业或交易目的。YMMV。
其他回答
不是邪恶的。它们实际上简化了事情
1.记录/审计对记录甚至数据库模式的更改
您可以在ALTER TABLE上设置一个触发器,用于回滚生产环境中的更改。这应该可以防止任何意外的表修改。
2.跨多个数据库强制执行引用完整性(主键/外键关系等)
如果有副作用,那就是故意造成的问题。 在一些数据库系统中,没有其他方法可以设置一个自增字段,即主键ID字段。
说他们是邪恶的是一种夸张,但他们可以引起网格。当一个触发器触发其他触发器时,情况就变得非常复杂了。让我们假设它们很麻烦:http://www.oracle.com/technology/oramag/oracle/08-sep/o58asktom.html
由于多并发问题,在Oracle中使用触发器执行业务逻辑比看起来要难。在其他会话提交之前,您不会在另一个会话中看到更改。
他们绝对不是邪恶的。我发现在重构数据库模式、重命名列或将列分成两列或相反(例如:姓名/姓氏情况)并协助转换时,触发器非常宝贵。
它们对于审计也非常有用。
触发器的概念并不邪恶,限制触发器的嵌套是邪恶的。