设计良好的应用程序中的策略 RE 数据库触发器？

Question

我听说过关于生活在数据库触发器中的小鬼的各种恐怖故事，而且——更糟糕的是——系统因添加触发器而导致一连串级联事件而崩溃。

我正在考虑实施关于使用数据库触发器的严格政策。对于关注点分离，最初的想法是说：

“数据库触发器应仅用于捕获和维护审计跟踪的目的。”

Answer 1

听起来我们对触发器的使用持有相似的观点，但我很想听听其他 DBA 的相反意见。就个人而言，我认为它们是最后的手段，并且只在没有其他选择的情况下实施触发器。例外是 INSTEAD OF 触发器针对视图。

当您增强 3rd 方解决方案并且系统 API 未公开扩展点时，触发器通常是唯一的选择。在我可以完全访问源代码的情况下，我还没有遇到过触发器是我第一个想到的情况。

审计就是一个很好的例子。在第 3 方应用程序中，触发器可能是唯一的选择。如果您可以访问源代码，它当然不是唯一的选择，尽管它可能是风险最低/最便宜/最简单（根据情况删除）的选项。如果数据库API设计的好，就会有其他的入口点来添加审计。

尽管我对触发器有想法，但我不会强加您建议的严格政策。在我看来，在许多组织中持续存在的 DBA 与开发人员的心态源于对此类指导的理解方式。尽量鼓励协商，而不是口授。

使用触发器进行审计日志记录的一个显着优势是它们可以从任何来源获取更改。如果您处于可以从应用程序外部进行更改（数据加载、支持修复、恶意更新）的情况，那么无论来源如何，触发器都会接收更改。使触发器和审计表由应用程序以外的帐户拥有，需要攻击者破坏应用程序以外的至少一个帐户，以篡改审计日志数据。 (2认同)

Answer 2

总体而言，触发器对您的数据修改性能有一种无声和隐藏的影响。

我见过这样的环境，其中级联错误是由从触发器内更新其他表引起的，并且更新的表具有触发器。

就审计而言，可以使用触发器，但如果您拥有 SQL Server 2008 或更高版本的企业版，您还可以使用变更数据捕获 (CDC) 功能。使用 CDC 功能消除了向审计表添加触发器的需要，并消除了隐藏性能影响的可能性。