关于TRIGGER的取舍（newkid进）

ljkcaizi · 发表于 2008-9-10 16:24

关于TRIGGER的取舍，见newkid在版里发表过多次意见：尽量不要用TRIGGER，用PROCEDURE代替TRIGGER
虽然很佩服newkid的专业水平，也对他的话深信不疑，不过还是不知道为什么
newkid同学能不能解释一下啊

还有，一些功能，在FORM上实现的，用PROCEDURE代替TRIGGER写起来有些困难，
不知道该如何解决

smallnavy · 发表于 2008-9-10 16:27

什么TRIGGER? 数据库TRIGGER的，还是FORM上的？

ljkcaizi · 发表于 2008-9-10 16:31

原帖由 smallnavy 于 2008-9-10 16:27 发表
什么TRIGGER? 数据库TRIGGER的，还是FORM上的？

数据库的，我想newkid同学所指的也应该是的数据库级的TRIGGER

newkid · 发表于 2008-9-10 22:45

哎，整得我像万峰老师似的……我确实说过类似的话，就再罗嗦一次好了：
我说的触发器是表上的，FORM上的触发器是另一种东西，该用就用。
每个触发器都是一个隐藏的存储过程。隐藏的代码对开发者很不友好。如果你正在看一段别人的程序，总觉得少了点什么，折腾半天原来还有些动作隐藏在触发器里！顺藤摸瓜去找了触发器，发现里面对其他表有DML，又有其他隐藏代码，是不是头很大？这种连锁触发增加了复杂性，很容易失控。起初我也做过这种东西，觉得系统布满了精巧的机关，很有成就感，后来才发现这对维护来说简直就是噩梦加陷阱。
因为触发器是隐藏的，它不执行你也不知道。假如有个触发器编译失效，DML还是不声不响的照样成功了！存储过程就不会这样。
触发器没有办法绕过。假如你有个产品正在跑，这时候需要补几条故障时间的历史数据，INSERT上的触发器有些动作是你不想要的，这就难办了。
触发器还有MUTATING TABLE问题。很多人一看这问题就上自治事务，殊不知这是个馊主意。自治事务使得你看到的数据都是旧的，因为主事务所作的修改还未提交。多行的DML会多次触发，产生一大堆小事务，很容易发生死锁。
在批量操作、多次触发到情况下，触发器的效率低，因为它相当于每次都执行一段PL/SQL. 往往可以把它转化为等价的几个SQL，效率提高很多。
暂时说这么多吧，大家想到再补充，也欢迎辩论。

阿日 · 发表于 2008-9-11 08:04

原帖由 zhangfengh 于 2008-9-10 16:29 发表
搬个凳子，继续等着newkid讲课

廖猫猫 · 发表于 2008-9-11 08:33

原帖由 newkid 于 2008-9-10 22:45 发表

因为触发器是隐藏的，它不执行你也不知道。假如有个触发器编译失效，DML还是不声不响的照样成功了！存储过程就不会这样。
触发器没有办法绕过。假如你有个产品正在跑，这时候需要补几条故障时间的历史数据，INSERT上的触发器有些动作是你不想要的，这就难办了。
触发器还有MUTATING TABLE问题。很多人一看这问题就上自治事务，殊不知这是个馊主意。自治事务使得你看到的数据都是旧的，因为主事务所作的修改还未提交。多行的DML会多次触发，产生一大堆小事务，很容易发生死锁。
在批量操作、多次触发到情况下，触发器的效率低，因为它相当于每次都执行一段PL/SQL. 往往可以把它转化为等价的几个SQL，效率提高很多。

学习了。
补充一句：像after update 的trigger是不能操作基表。