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

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

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

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


当前回答

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

其他回答

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

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

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

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

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

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

我认为它们可以是邪恶的,但只能和其他正在开发的东西一样邪恶。

虽然我并没有太多使用它们的经验,但我在最近的一个项目中使用了它们,这让我得出了这个结论。我遇到的问题是,它们可能导致业务逻辑在两个位置结束,一个代码库和一个数据库。

我认为这与使用scprocs类似。您经常会遇到一些开发人员,他们非常擅长将业务逻辑写入SQL到数据库中,而那些不擅长的人将业务逻辑放在其他地方。

所以我的经验法则是看看你项目的结构是什么。如果在数据库中存储业务逻辑似乎是可行的,那么使用触发器可能是有用的。

他们绝对不是邪恶的。我发现在重构数据库模式、重命名列或将列分成两列或相反(例如:姓名/姓氏情况)并协助转换时,触发器非常宝贵。

它们对于审计也非常有用。