数据库 – 触发器与存储过程非正规化的优缺点

前端之家收集整理的这篇文章主要介绍了数据库 – 触发器与存储过程非正规化的优缺点前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
当谈到事务数据库中的数据进行非规范化处理时,有(至少)三种不同的方法

>通过更新标准化事务数据和非规范化报告/分析数据的存储过程来推送更新;
>在更新次表的事务表上实施触发器;这几乎总是保持历史的路线;
>将处理延迟到夜间批处理,可能在数据集市/仓库中进行ETL.

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

我已经使用了前两种方法,最近我一直倾向于基于触发器的方法,但是我想知道是否有任何我还没有发现的“陷阱”,并且认为值得问这个问题,所以在今后作出长期的决定时,我会想出一些想法.

所以在你的经验中,为保持实时的非规范化数据的具体目的,任一工具的利弊是什么?在什么情况下你会选择一个在另一个,为什么?

(请参阅“触发器太复杂”或“所有更新应始终通过存储过程”的答案 – 使其适合于问题的上下文).

解决方法

触发器在表上有多个更新路径时很有用.

我们使用存储过程,至少有4条路径(Add,Update,Deactivate,Copy)

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

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

现在,触发器中的TRY / CATCH意味着正确的,可预测的错误处理:sql Server 2000和更早版本上的触发器导致批处理中止错误/回滚,这不是理想的(至少说!).所以触发器现在更加可靠.

猜你在找的MsSQL相关文章