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

Aar*_*ght 10 database triggers stored-procedures denormalization sql-server-2008

当涉及在事务数据库中对数据进行非规范化以提高性能时,存在(至少)三种不同的方法:

  1. 通过存储过程推送更新,存储过程更新规范化的事务数据和非规范化的报告/分析数据;

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

  3. 将处理推迟到夜间批处理过程,可能将ETL放入数据集市/仓库.

让我们假设为了这个问题的目的,选项#3是不可行的,因为域要求非规范化数据始终与规范化数据一致.我经常处理的分层聚合就是其中的一个例子.

我已经使用了前两种方法中的两种方法,最近我一直倾向于基于触发器的方法,但我想知道是否有任何"陷阱"我尚未发现,并认为它值得问这个问题所以我在将来作出长期决定时会记住一些想法.

那么根据您的经验,这两种工具的优缺点是什么,以保持实时非规范化数据的特定目的?在什么情况下你会选择一个而不是另一个,为什么?

(PS请不要回答"触发器过于复杂"或"所有更新应始终通过存储过程" - 使其适合问题的上下文.)

gbn*_*gbn 9

在表上有多个更新路径的情况下,触发器很有用.

我们使用存储过程并至少有大约4个路径(添加,更新,取消激活,复制)

使用我们刚刚在触发器中插入/更新的数据更容易,无论我们采取什么操作或我们影响了多少行.

存储过程只适用于单个更新路径我觉得:除非你想重复代码......

现在,触发器中的TRY/CATCH意味着正确,可预测的错误处理:SQL Server 2000及更早版本上的触发器导致错误/回滚的批量中止,这是不理想的(至少可以说!).因此,无论如何,触发器现在更可靠.

  • 仅当您希望将系统/数据保持在不一致状态时.这里背景文章中的一些信息:http://www.sommarskog.se/error_handling_2005.html (3认同)

小智 8

触发器是自动副作用,并且当你想要做某事时几乎肯定会让你失望,因为触发器的副作用而不能.主要是让您的系统参与与其他外部系统的某些XA事务.触发器使这个不可能.它也是副作用逻辑,只能通过再次执行触发激活器来激活.如果你想在仓库中重新创建数据,你不能只运行一些程序并重新创建它,你必须执行所有会触发触发器的活动,这是一场噩梦.INSERTS,UPDATES和DELETES应该是幂等的和正交的.触发器不必要地使工作流程复杂化,即使您认为它们是简化它们而不是它们.