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

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

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

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

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

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

不，其实这是个好主意。如果你的特定触发器有问题，那么你做得不对，但这通常意味着你的实现有问题，而不是触发器本身的概念:-)。

我们经常使用触发器，因为它将特定于dbms的活动置于其所属数据库的控制之下。DBMS的用户不应该担心这类事情。数据的完整性取决于数据库本身，而不是使用它的应用程序或用户。如果数据库中没有约束、触发器和其他特性，执行规则的任务就留给了应用程序，只需要一个流氓或有bug的应用程序/用户就可以破坏数据。

例如，如果没有触发器，像自动生成列这样奇妙的东西就不存在了，在选择它们时，您必须在每行上处理一个函数。这可能会降低DBMS的性能，在插入/更新时创建自动生成的列要好得多，因为只有在插入/更新时才会更改列。

此外，缺乏触发器将阻止在DBMS中强制执行数据规则，例如预先触发器，以确保列具有特定的格式。注意，这与数据完整性规则不同，后者通常只是外键查找。

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

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

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

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

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