我公司的业务部门希望实施 20 个具有非常具体业务逻辑的新触发器。他们还不断地对旧触发器进行更改。逻辑只是 99% 的时间取决于参数的组结构。
我已经一次又一次地尝试阻止这种情况，但他们现在已经习惯了这个过程并期待它。如果我不同意，我会被告知我仍然必须实施这些。
我需要用非技术术语向他们概述，让他们理解为什么我们不应该实现这些触发器并将这些任务转移到我们的应用程序中开发。
到目前为止，我已经告诉他们：
还有其他项目可以添加到此列表中吗？
如果这里不适合提出这个问题，我们深表歉意。
谢谢！
【问题讨论】：
您给出的三个原因是错误的，并且背叛了纯编码员的观点：
数据丢失/覆盖的风险极高
（如果你的东西是用一种碰巧没有命名为 SQL 的语言编码的，你就没有这种风险？）
以 $ 为单位的高 DB 成本
（如果你的东西是用一种碰巧没有命名为 SQL 的语言编码的，你就没有这种风险？）
可以通过应用程序自动化的不必要的工作
（用一种碰巧没有命名为 SQL 的语言自动化你的东西不是一个涉及进行分析和编写实现代码的过程？）
触发器是一种有用的构造，至少有一个目的：针对 SQL 以声明方式不支持的所有完整性规则保护数据完整性。有关详细信息，请参阅“数据库专业人员的高级数学”，第 11 章。
所有这一切：设计师应该注意将 [执行] 代码附加到例如 INSERT INTO CUSTOMER 的原因是“只有在我们注册新客户时才会发生这种情况，并且所有新客户都应该收到一封欢迎信（或一些这样的）”。考虑您接管另一家公司，其所有客户都将集成到您的数据库中。哎哟。触发器的不良使用通常可以追溯到“过于急切地将业务意义附加到正在发生的数据库操作上”。这个特殊的东西确实属于“业务事务/业务功能”编码的部分，可能是应用程序代码，或者可能是可调用的存储过程（与触发器不同）。
【讨论】：
我真的不喜欢业务逻辑的触发器，所以这可能更像是一个咆哮而不是答案......
触发器会产生性能问题和锁定的风险。没有什么可以阻止您编写具有可怕性能特征的触发器，或者更有趣的触发器来触发触发原始触发器的其他触发器。
触发器是“副作用”，对于大多数人来说，副作用通常会导致错误。例如，如果有人正在编写用于持久化新业务实体的代码，并且该代码导致触发触发器，他们可能不会在其代码中考虑这一点，从而导致错误。
如果你的回答是“好吧，不要做那些事”：
【讨论】：