案例：我有一张表格T1，通过表格保存提交记录。在更新此表上的记录时，我想在 table 中插入一行T2。
对于这种情况，以下场景的性能将如何比较？
场景 A：AFTER UPDATE ON T1触发器构建并插入相关行。由于T1没有引用T2，这没关系。
场景 B：服务器端服务层（PHP、python 等）在进行更新后插入相关行。
场景 C：这将是存储过程，但是 SP 和触发器的比较有很多，因此您不必包括它们。
问问题
857 次
4 回答
4
我真的不喜欢触发器。问题是它们本质上是副作用，因此往往是隐藏的，对系统的未来维护者来说并不明显。它们会导致以后出现错误的代码。除非您有特定数据显示此特定用例的性能瓶颈，否则我更愿意查看存储过程或处理对数据库的所有访问的“PHP、python 等”服务层。永远不要忽视正确性胜过性能这一事实。
于 2012-10-09T19:21:19.907 回答
2
考虑到触发器和 python 之间的选择，我会选择触发器。无论数据如何插入，您的数据上的触发器确保 T2 包含 T1 的记录，而不是依赖于应用程序，从而确保数据的完整性。如果您添加另一个向 T1 添加记录的应用程序，使用触发器，T2 仍会插入记录。
不过，我不知道为什么您会打折存储过程，也不知道您从哪里得到触发器更快或“更适合数据库服务器的性质”的想法
于 2012-10-09T19:22:33.333 回答
1
如果您可以保证数据始终且仅T1通过您的应用程序更新，我会投票支持在代码（PHP/Python 或存储过程）中执行此操作。如果有任何可能以另一种方式更新数据（也许是 DBA 编写查询？），那么请使用触发器以保证您获得预期的一致结果。
于 2012-10-09T19:23:18.143 回答
0
无论使用触发器和/或存储过程，您的 sql 代码都会被预编译和优化。我怀疑是否存在显着的性能优势。正如其他人所指出的，触发器可能会在更新表上的多个记录时导致意外的性能问题，或者创建难以管理的更新链。
与触发器链相比，您将更容易重构和维护存储过程。
于 2012-10-09T19:26:55.690 回答