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

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

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

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


当前回答

不,他们不邪恶——他们只是被误解了:- d

触发器有一个有效的用途,但往往是作为一个复古黑客,最终使事情变得更糟。

如果您将DB作为应用程序的一部分进行开发,那么逻辑应该始终存在于进行调用的代码或scprocs中。触发器只会导致稍后的调试痛苦。

如果您了解锁、死锁以及DB如何访问磁盘上的文件,那么以正确的方式使用触发器(例如审计或归档直接DB访问)将非常有价值。

其他回答

触发器的主要问题是

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

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

不,他们不邪恶——他们只是被误解了:- d

触发器有一个有效的用途,但往往是作为一个复古黑客,最终使事情变得更糟。

如果您将DB作为应用程序的一部分进行开发,那么逻辑应该始终存在于进行调用的代码或scprocs中。触发器只会导致稍后的调试痛苦。

如果您了解锁、死锁以及DB如何访问磁盘上的文件,那么以正确的方式使用触发器(例如审计或归档直接DB访问)将非常有价值。

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

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

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

工具从来都不是邪恶的。 这些工具的应用可能是邪恶的。