sql - 为什么我们不应该在数据库触发器中包含业务逻辑？

Question

我公司的业务部门希望实施 20 个具有非常具体业务逻辑的新触发器。他们还不断地对旧触发器进行更改。逻辑只是 99% 的时间取决于参数的组结构。

我一次又一次地尝试阻止这种情况，但他们现在已经习惯了这个过程并期待它。如果我不同意，我被告知我仍然必须实施这些。

我需要用非技术术语向他们概述，他们会理解为什么我们不应该实现这些触发器并将这些任务转移到我们的应用程序中进行开发。

到目前为止，我已经告诉他们：

1. 数据丢失/覆盖的高风险
2. 以美元为单位的高数据库成本
3. 可以通过应用程序自动化的不必要的工作

是否有任何其他项目可以添加到此列表中？

如果这不是问这个问题的正确地方，我们深表歉意。

谢谢！

1. 数据丢失/覆盖的高风险
2. 以美元为单位的高数据库成本
3. 可以通过应用程序自动化的不必要的工作

标签： sqldatabasetriggers

Answer 1

您给出的三个原因是错误的，并且背叛了纯编码器的观点：

1. 数据丢失/覆盖的高风险

   （如果你的东西是用一种碰巧没有命名为 SQL 的语言编码的，你就没有这种风险吗？）

2. 以美元为单位的高数据库成本

   （如果你的东西是用一种碰巧没有命名为 SQL 的语言编码的，你就没有这种风险吗？）

3. 可以通过应用程序自动化的不必要的工作

   （用一种碰巧没有命名为 SQL 的语言自动化你的东西不是一个涉及进行分析和编写实现代码的过程？）

触发器是一种有用的构造，至少有一个目的：针对 SQL 以声明方式不支持的所有完整性规则保护数据完整性。有关详细信息，请参阅“数据库专业人员的高级数学”，第 11 章。

所有这一切：设计师应该注意将 [执行] 代码附加到例如 INSERT INTO CUSTOMER 的原因是“只有在我们注册新客户时才会发生这种情况，并且所有新客户都应该收到一封欢迎信（或一些这样的）”。考虑您接管另一家公司，并将其所有客户都集成到您的数据库中。哎哟。触发器的不良使用通常可以追溯到“过于急切地将业务意义附加到正在发生的数据库操作上”。这个特定的东西确实属于“业务事务/业务功能”编码的部分，可能是应用程序代码，或者可能是可调用的存储过程（与触发器不同）。