比较 oracle 和 SQL Server 的 Trigger

tank209

Oracle 有 row-level 和 statement-level  的触发器，
SQL Server 只有 statement-level 的触发器。

Oracle  row-level 触发器中可以用 :New 和 :Old 来引用
新 row 和旧 row中的字段， Oracle 的 statement-level触发器
不能引用新旧值。 SQL Serve中用 inserted, deleted
临时表来引用新的和旧的 rows.

想不出真正意义上的 row-level 触发器有什么应用不能
用 statement-level 的触发器 + inserted, deleted tables
来实现的。

Row-level 触发器看起来强大，实际上引出很多复杂的问题，
很容易造成 mutating table errors，到头来还得用
statement-level触发器来 work-around (actually 要用
两个statement-level 的触发器和一个Row-level 触发器来
做SQL Serve中一个触发器就能做到到的功能).

至少从本人的经验来看，多半的触发器都要用该work-around
来避免mutating table errors。

当然, Oracle 触发器有些方面功能更全面。

本人浅见：Oracle 的 触发器的设计有根本缺陷。不知各位
高手有何高见。

redtulip

as subject.

biti_rainy

只是不知道
这么做的话

假如存在一个很大的表中批量的操作产生（比如200G的一个表？）
这两个临时表会有多大？
我不知道语句级的trigger，是先把符合条件的集合弄出来做成临时表呢还是……？
这个临时表是不是最后包含了所有的记录集合？

通常来说，临时表还不存在索引的
这样对效率又有多大的影响？

很多问题我也不是确信
希望大家多探讨设计上的根源

关于  mutating table errors  这个问题
有设计上的其他原因
在csdn上曾经有过激烈的讨论
只可惜没有保留下来

tank209

inserted 和 deleted 临时表的设计是可能有
performance 的问题，尤其是当job batch 牵涉很多
行的时候。但以本人经验，这种大的batch
如果触发一个trigger 的话，这种trigger
不应该去引用 inserted 和 deleted 临时表，
否则设计上说不过去。即使这样的
trigger 不能避免，在Oracle 中也得用
三个trigger 的 work-around 来实现，
这个 work-around 本质上和inserted 和
deleted临时表是以回事，performance
似乎也不会有本质的区别。

总之，让一个程序员每天去用三个trigger
来做直观上和（别的DB）实际上一个trigger
就能做到的事，不能说不是一个遗憾。
我要是设计出这样的东东，我会愧对全世界
数以万计的Oracle程序员的

tank209

简单来说，就是行级触发器中不能引用和修改那个
引发这个触发器的表中的任何内容，否则
运行当中就会造成 mutating table error.

也就是说：

  create trigger my_trigger
    after update of my_table
    for each row
    begin
    ...（不能引用和修改my_table）
    end;

详细讲解可以到这里：

http://osi.oracle.com/~tkyte/Mutate/index.html

biti_rainy

我个人并不认为一定要通过3个trigger来解决这个问题
应该可以有其他的变通的方式

1: 不使用trigger而直接使用存储过程
2：oracle提供了自治事务，可以结合起来解决这类问题（search  pragma）