Database 触发器与非规范化存储过程的优缺点

为了提高性能而对事务数据库中的数据进行非规范化时，有（至少）三种不同的方法：

通过存储过程推送更新，存储过程更新规范化事务数据和非规范化报告/分析数据

在更新辅助表的事务表上实现触发器；这几乎总是维持历史时所采取的路线

将处理推迟到每晚的批处理过程，可能是对数据集市/仓库进行ETL

为了解决这个问题，我们假设选项#3不可行，因为域要求非规范化数据始终与规范化数据一致。我经常处理的层次聚合就是一个例子

我已经使用了前两种方法，最近我倾向于基于触发器的方法，但我想知道是否有我还没有发现的“陷阱”，我认为值得问这个问题，所以在未来做出长期决策时，我会记住一些想法

根据您的经验，对于维护实时非规范化数据的特定目的，这两种工具的优缺点是什么？在什么情况下，你会选择一种而不是另一种，为什么

---

（请注意，不要回答“触发器太复杂”或“所有更新都应始终通过存储的过程”-使其适合问题的上下文。）

当您在一个表上有多个更新路径时，触发器非常有用

我们使用存储过程，至少有4条路径（添加、更新、停用、复制）

无论我们执行什么操作或影响多少行，都可以更轻松地处理刚刚插入/更新到触发器中的数据

一个存储的进程只适用于一个更新路径我觉得：除非你想重复代码

---

现在，TRY/CATCH-in触发器意味着正确的、可预测的错误处理：SQLServer2000和更早版本上的触发器在错误/回滚时导致批处理中止，这是不理想的（至少可以这么说！）。因此，触发器现在无论如何都更加可靠。

触发器是自动的副作用，几乎肯定会在您想做某事而由于触发器的副作用而做不到的时候咬到您。主要是让您的系统参与与其他外部系统的某些XA事务。触发器使这不可能。此外，副作用逻辑只能通过再次执行触发器激活器来激活。如果您想在仓库中重新创建数据，您不能只运行某个过程并重新创建它，您必须执行将触发触发器的所有活动，这是一场噩梦。插入、更新和删除应该是幂等的和正交的。触发器不必要地使工作流复杂化，即使您认为它们正在简化工作流，但事实并非如此。

这取决于您的业务需求和数据库的使用方式。例如，假设有许多应用程序和许多导入会影响表（我们有数百种东西会影响表）。假设有时还需要编写从SSM运行的查询（即使在prod上也是如此），以执行诸如将所有价格更新10%之类的操作。如果您执行这些类型的操作，那么存储过程是不切实际的，您将永远不会有任何可能的方法来影响所涵盖的数据库

如果此数据更改对于数据完整性是必需的，或者许多应用程序或进程（导入、SQL Server作业等）可能会影响数据，则它属于触发器

---

如果有时只需要更改数据，或者您可以完全控制如何从一个应用程序更改数据，那么存储过程就可以了

我很好奇-如果触发器发生错误，为什么您不想中止？是否存在允许将触发器的工作保留为未完成（或半完成）的情况？仅当您希望将系统/数据保留为不一致状态时。背景文章中的一些信息：使用物化视图进行非规范化不是更好吗？@Enrique：物化视图不是灵丹妙药；有各种各样的视图实际上都不能具体化（甚至不能通过模式绑定创建），即使可以，它们的性能特征也与触发器大致相同。我一直在讨论是否使用存储过程和触发器。我可以很快决定不使用存储过程，但触发器有问题。你为我解决了这个问题：他们使工作流程复杂化的原因对我来说已经足够了。：-）这是我对触发器的最大担忧之一。基于副作用的逻辑只对异步、非原子行为和UI真正有意义。