当谈到对事务数据库中的数据进行非规范化以提高性能时，（至少）有三种不同的方法：
通过存储过程推送更新，该存储过程更新规范化的事务数据和非规范化的报告/分析数据；
在更新辅助表的事务表上实现触发器；这几乎是维护历史时所采取的路线；
将处理推迟到夜间批处理，可能会在数据集市/仓库中执行 ETL。
出于这个问题的目的，我们假设选项 #3 不可行，因为域要求非规范化数据始终与规范化数据一致。我经常处理的分层聚合就是一个例子。
我已经相当多地使用了前两种方法，最近我一直倾向于基于触发器的方法，但我想知道是否有任何“陷阱”我还没有发现，并认为它值得问这个问题，所以我在未来做出长期决定时会有一些想法要记住。
因此，根据您的经验，对于维护实时非规范化数据的特定目的，这两种工具的优缺点是什么？在什么情况下你会选择其中一种，为什么？
（PS 请不要回答“触发器太复杂”或“所有更新应始终通过存储过程”之类的答案 - 使其适合问题的上下文。）
触发器是自动的副作用，当你想做某事但由于触发器的副作用而不能做时，几乎肯定会咬你。主要是让您的系统与其他外部系统参与一些 XA 事务。触发器使这成为不可能。此外，它是副作用逻辑，只能通过再次执行 Trigger 激活器来激活。如果你想在仓库中重新创建数据，你不能只运行一些程序并重新创建它，你必须执行所有会触发触发器的活动，这是一场噩梦。INSERTS、UPDATES 和 DELETES 应该是幂等的和正交的。触发器不必要地使工作流程复杂化，即使您认为它们正在简化它们，但事实并非如此。
触发器在您对表有多个更新路径的情况下很有用。
我们使用存储过程并且至少有大约 4 条路径（添加、更新、停用、复制）
无论我们执行什么操作或影响多少行，都可以更轻松地处理我们刚刚在触发器中插入/更新的数据。
存储过程仅适用于单个更新路径：除非您想重复代码...
现在，触发器中的 TRY/CATCH 意味着正确的、可预测的错误处理：SQL Server 2000 和更早版本上的触发器导致错误/回滚时批处理中止，这并不理想（至少可以这么说！）。所以，无论如何，触发器现在更可靠了。
这取决于您的业务需求以及您的数据库的使用方式。例如，假设有许多应用程序和许多影响表的导入（我们有数百个可以影响表的事物）。假设偶尔还需要编写从 SSMS 运行的查询（是的，即使在 prod 上也是如此）来执行诸如将所有价格更新 10% 之类的事情。如果你做这些类型的事情，那么存储过程是不切实际的，你永远不会有所有可能的方式来影响所覆盖的数据库。
如果此数据更改对于数据完整性是必要的，或者许多应用程序或进程（导入、SQL Server 作业等）会影响数据，则它属于触发器。
如果仅有时需要更改数据，或者您可以完全控制如何仅从一个应用程序更改数据，那么存储过程就可以了。