触发器，我们真的需要吗

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