根据我的经验,它们不是一个好主意,因为它们可能会导致令人惊讶的副作用,并且很难调试(特别是当一个触发器触发另一个触发器时)。通常情况下,开发人员甚至不会考虑是否存在触发因素。
另一方面,如果每次在数据库中创建新FOO时都必须执行逻辑,那么将其放在FOO表上的插入触发器可能是最安全的地方。
我们唯一使用触发器的时候是非常简单的事情,比如设置一行的修改日期字段。
我正在努力弄清楚触发器是否有必要,并感谢任何建议。如果它们是必要的,在实施它们时要考虑的最重要的问题是什么?
根据我的经验,它们不是一个好主意,因为它们可能会导致令人惊讶的副作用,并且很难调试(特别是当一个触发器触发另一个触发器时)。通常情况下,开发人员甚至不会考虑是否存在触发因素。
另一方面,如果每次在数据库中创建新FOO时都必须执行逻辑,那么将其放在FOO表上的插入触发器可能是最安全的地方。
我们唯一使用触发器的时候是非常简单的事情,比如设置一行的修改日期字段。
我正在努力弄清楚触发器是否有必要,并感谢任何建议。如果它们是必要的,在实施它们时要考虑的最重要的问题是什么?
当前回答
如果有副作用,那就是故意造成的问题。 在一些数据库系统中,没有其他方法可以设置一个自增字段,即主键ID字段。
其他回答
说他们是邪恶的是一种夸张,但他们可以引起网格。当一个触发器触发其他触发器时,情况就变得非常复杂了。让我们假设它们很麻烦:http://www.oracle.com/technology/oramag/oracle/08-sep/o58asktom.html
由于多并发问题,在Oracle中使用触发器执行业务逻辑比看起来要难。在其他会话提交之前,您不会在另一个会话中看到更改。
大多数情况下,是的。
扳机的困难在于它是“在你背后”做事情的;维护应用程序的开发人员很容易没有意识到它的存在,甚至在没有注意到的情况下做了一些更改,把事情搞砸了。
它增加了一层复杂性,增加了维护工作。
不使用触发器,存储过程/例程通常可以做同样的事情,但以一种清晰和可维护的方式-调用存储例程意味着开发人员可以查看其源代码并确切地了解发生了什么。
如果有副作用,那就是故意造成的问题。 在一些数据库系统中,没有其他方法可以设置一个自增字段,即主键ID字段。
触发器有它们的用途——日志记录/审计和维护“最后修改”日期是两个非常好的用途,在之前的回复中已经提到过。
然而,优秀设计的核心原则之一是业务规则/业务逻辑/无论你想称呼它什么,都应该集中在一个地方。将一些逻辑放在数据库中(通过触发器或存储过程),将一些逻辑放在应用程序中违反了这一原则。在两个地方复制逻辑更糟糕,因为它们总是会彼此不同步。
还有一个已经提到过的“最小意外原则”问题。
他们绝对不是邪恶的。我发现在重构数据库模式、重命名列或将列分成两列或相反(例如:姓名/姓氏情况)并协助转换时,触发器非常宝贵。
它们对于审计也非常有用。