不用触发器的理由

      TOM说过他希望三样东西不曾存在：触发器，自治事务，WHEN OTHERS。

      现在开发用的触发器都是表上的，FORM上的触发器是另一种东西，该用就用。每个触发器都是一个隐藏的存储过程。隐藏的代码对开发者很不友好。如果你正在看一段别人的程序，总觉得少了点什么，折腾半天原来还有些动作隐藏在触发器里！顺藤摸瓜去找了触发器，发现里面对其他表有DML，又有其他隐藏代码，是不是头很大？这种连锁触发增加了复杂性，很容易失控。起初我也做过这种东西，觉得系统布满了精巧的机关，很有成就感，后来才发现这对维护来说简直就是噩梦加陷阱。

       因为触发器是隐藏的，它不执行你也不知道。假如有个触发器编译失效，DML还是不声不响的照样成功了！存储过程就不会这样。触发器没有办法绕过。假如你有个产品正在跑，这时候需要补几条故障时间的历史数据，INSERT上的触发器有些动作是你不想要的，这就难办了。

       触发器还有MUTATING TABLE问题。很多人一看这问题就上自治事务，殊不知这是个馊主意。自治事务使得你看到的数据都是旧的，因为主事务所作的修改还未提交。多行的DML会多次触发，产生一大堆小事务，很容易发生死锁。 在批量操作、多次触发到情况下，触发器的效率低，因为它相当于每次都执行一段PL/SQL. 往往可以把它转化为等价的几个SQL，效率提高很多。

        触发器是低效的，当做大数据量修改的时候，每行触发一次触发器，性能将非常之差。

        级联删除、级联修改，在设计良好的系统中是不存在的。即使有，那也是小概率事件，必须专门写一段脚本来解决，而不是作为常规功能存在。

        非要说触发器适用于哪种场景：当Oracle提供表字段的校验规则不够用（非空、唯一），需要一个非常复杂的校验规则时。