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

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

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

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

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

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

不是邪恶的。它们实际上简化了事情

1.记录/审计对记录甚至数据库模式的更改

您可以在ALTER TABLE上设置一个触发器，用于回滚生产环境中的更改。这应该可以防止任何意外的表修改。

2.跨多个数据库强制执行引用完整性(主键/外键关系等)

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

触发器的概念并不邪恶，限制触发器的嵌套是邪恶的。

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

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

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

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