SQL触发器与服务器端查询[关闭]答案

【问题标题】：SQL Triggers vs server side queries [closed]SQL触发器与服务器端查询[关闭]
【发布时间】：2012-10-09 19:16:31
【问题描述】：

案例：我有一张表格T1，通过表格保存提交记录。在更新此表上的记录时，我想在表 T2 中插入一行。

对于这种情况，以下场景的性能比较如何？

场景 A：AFTER UPDATE ON T1 触发器构建并插入相关行。因为T1 没有引用T2，所以没关系。

场景 B：服务器端服务层（PHP、python 等）在进行更新后插入相关行。

场景 C：这将是存储过程，但是 SP 和触发器的比较有很多，因此您不必包括它们。

【问题讨论】：

在触发器中发现错误可能会很痛苦，因为它们会混淆信息。如果您的情况允许，我会进行程序（更容易测试一件事）

标签： sql database triggers webserver sql-update

【解决方案1】：

我真的不喜欢触发器。问题是它们本质上是副作用，因此往往是隐藏的，对系统的未来维护者来说并不明显。它们会导致以后出现错误的代码。除非您有特定数据显示此特定用例的性能瓶颈，否则我更愿意查看存储过程或处理对数据库的所有访问的“PHP、python 等”服务层 .永远不要忽视正确性胜过性能这一事实。

【讨论】：

谢谢，是的，我的意思是通过服务层完成这项工作。最后三个词使它非常（不过分）简单。

【解决方案2】：

考虑到触发器和 python 之间的选择，我会选择触发器。数据上的触发器确保无论数据如何插入，T2 都包含 T1 的记录，而不是依赖于应用程序，从而确保数据的完整性。如果您添加另一个向 T1 添加记录的应用程序，使用触发器，T2 仍然会插入记录。

我不知道您为什么不重视存储过程，也不知道您从哪里得到触发器更快或“更适合数据库服务器的性质”的想法

【讨论】：

谢谢。正如 Joe 所提到的，诚信是一个非常重要的问题，触发因素可以消除许多风险。
至于我得到的想法，主要来自我在 SO 和其他一些地方在 5 分钟左右读到的内容。说“我知道 (...)”可能有点过分了，是的。

【解决方案3】：

如果您可以保证数据始终且仅通过您的应用程序在T1 中更新，我会投票支持使用代码（PHP/Python 或存储过程）进行更新。如果有可能以另一种方式更新数据（也许是 DBA 编写查询？），那么请使用触发器以保证您获得预期的一致结果。

【讨论】：

非常感谢您指出确保通过服务层进行更新是一个重要问题。

【解决方案4】：

无论使用触发器和/或存储过程，您的 sql 代码都会被预编译和优化。我怀疑是否存在显着的性能优势。正如其他人所指出的，触发器可能会在更新表上的多个记录时导致意外的性能问题，或者创建难以管理的更新链。

与触发器链相比，重构和维护存储过程会更容易。

【讨论】：