我们真的需要触发器吗？
摘要： 作者是一位生产环境 DBA 和数据库顾问，他反对在 PostgreSQL 中使用触发器。虽然触发器有合理的内部用途，但当交给开发人员使用时往往会带来更多问题。触发器应该只由专家使用，即使如此，替代方案（如 CTE）通常更可取。
2023 年 4 月 7 日 · 615 词 · 3 分钟阅读
原文链接
免责声明
我的观点来自多年作为生产环境 DBA 以及后来作为数据库顾问的实践经验。作为一名专业人士，我的观点带有偏见，因为我从未在系统正常运行时被召唤！我总是在出现问题时（通常是大问题）被请去，所以看到的都是开发人员能造成的最糟情况，而从未见过最好的情况。我试图意识到这种偏见，但这并不容易。
为什么我希望开发人员停止使用触发器
触发器在 PostgreSQL 内部用于强制外键、分区等场景时表现良好。但每次你想到"哦，我可以用触发器做到这一点"时，请重新考虑一下。
我认为将触发器交给开发人员就像把锋利的刀交给幼儿。请停止伤害我亲爱的数据库！我见过太多管理不善、维护不当的数据库，真是令人心碎！触发器不是唯一的罪魁祸首（当然），但这种情况足够普遍，以至于当一位大学教师——我的朋友——问我如何向学生教授触发器时，我的回答是："请不要。教他们 CTE、窗口函数、过滤子句、高级聚合，但不要教触发器！"
触发器会带来性能损失，当你的数据库规模增长时，可能会造成严重伤害。也许更值得做的是改变你的应用程序查询？如果你担心因为一个表上的更新需要写多个查询来更新多个表，也许是时候学习一下 CTE 了。
触发器有合法的用例吗？
这个问题我纠结了很久。首先，一些词汇定义，当我写"触发器"时，我指的是专门为你的数据库编写的触发器，而不是在后台使用触发器的扩展。如果一个扩展在很多生产环境中使用，它写得不好的概率会更小。
- 人们通常认为审计是触发器的合法用例。我不这么认为。审计 DDL（数据定义语言）或 DML（数据修改语言）可以通过将你的 DDL 或 DML 查询记录到 PostgreSQL 日志中（CSV 格式，我最喜欢的）来完成，然后你可以使用外部数据包装器将这些文件挂载到另一个数据库中用 SQL 查询它。如果你认为需要更多选择来挑选你想要审计的对象和/或事件，请使用 pgadudit 扩展。如果你需要如何利用 SQL 利用 PostgreSQL 日志的示例，请看我自己的扩展 pglog。
- 另一个常被提及的用例是向表中添加"技术字段"，比如谁做了修改、何时修改等。我的回答是：这与审计的目的是一样的，所以使用审计！
我想说的是，你应该非常谨慎地做出这类设计决策，因为它将对你、你的团队和你的公司未来产生影响。
简而言之
如你所知，我讨厌触发器，因为通常感觉是开发人员太懒了，决定"在数据库中做一个小改动"，而不是在应用程序中做同样的改变。在 IT 领域懒惰是件好事，因为你会在需要重复执行任务时自动化它。但在做出设计决策时，懒惰可能是一种诅咒。
所以，让我们基于两条"优化规则"创建两条"触发器规则"：
- 如果你不是专家，不要做。
- 如果你是专家，先不要做。
标签： PGSQL Phriday · PostgreSQL
