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

Question

我公司的业务部门希望使用非常具体的业务逻辑实施20个新触发器。他们还不断地改变旧的触发器。逻辑只是组结构，在99％的时间内取决于参数。

我已经一次又一次尝试停止此操作，但是他们现在已经习惯了此过程，并期待它。如果我不同意，我会被告知仍然必须执行这些。

我需要以非技术性的眼光来概述他们，以便他们理解为什么我们不应该实施这些触发器并将这些任务移到我们的应用程序中进行开发。

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

1. 数据丢失/覆盖的严重风险
2. $ DB的数据库成本很高
3. 可以通过应用程序自动化的不必要的工作

还有其他可以添加到此列表中的项目吗？

很抱歉，如果这不是问这个问题的正确地方。

谢谢！

1. 数据丢失/覆盖的严重风险
2. $ DB的数据库成本很高
3. 可以通过应用程序自动化的不必要的工作

Answer 1

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

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

   （如果您将自己的东西用一种刚好不会被命名为SQL的语言进行编码，就不会有这种风险）

2. $ DB中的数据库成本很高

   （如果您将自己的东西用一种刚好不会被命名为SQL的语言进行编码，就不会有这种风险）

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

   （使用一种刚好不会被命名为SQL的语言来自动化您的内容，这不是一个涉及进行分析和编写实现代码的过程吗？）

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

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

Answer 2

我真的不喜欢业务逻辑触发器，所以这可能更多的是麻烦而不是答案...

1. 触发器会引发性能问题和锁定的风险。没有什么可以阻止您编写具有糟糕性能特征的触发器，甚至更有趣的触发器可以触发其他触发原始触发器的触发器。

2. 触发器是“副作用”，对于大多数人而言，副作用通常会导致错误。例如，如果某人正在研究用于保留新业务实体的代码，并且该代码导致触发触发器，那么他们可能不会在其代码中考虑这一点，从而导致错误。

如果您的回答是“好吧，不要做那些事”：

1. 触发器真的很难测试。您必须测试可能导致触发器触发的每条路径，而在非平凡的应用程序上，这通常是不可能的。