(05) 触发器(Trigger)的维护困境

 触发器(trigger)在维护中的斑斑劣迹，我碰到的那是数不胜数.

        首先不是说trigger不好,数据库都提供这个技术,自然有它的好处. 

其中之一, 处理某些业务时特别简便.

    如当A的变更需要影响到B时, 触发器的事件可以马上知道这件事,不管是行级,还是表级,还是列级触发器功能都相当强大.

利用它的特性,开发可以很方便的在发生这些更改事件的前后或中间做一系列的动作. 早年间我也常用它，

可正因为它太好用了.随着项目的推进，问题就跟着来了.

       问题1: 上线后的维护困难

                当程序有错误或其它各种原因，需要仅更改某个表的资料时（这种现象相当常见), 你如果用到触发器，你将面临

一个困境，如果不停用当前的触发器，更改时将会引起连锁反应，而要停用触发器，未知的风险同样巨大。

       问题2:   将业务逻辑分割得支离破碎

             本来一个很顺的处理流程，开发人员为了省事或赶速度，把一段段逻辑代码分散在了一个个触发器中，经常解发器影响一

一个表，这个表本身又有它的触发器，或在触发器中调用存储过程，存储过程所影响的表又有触发器。

            整个流程被完全分割，处理失控状态。  更可怕的是，如果开发人员有更换。新人接手时将面临一个很惨的困境。

     

       问题3: 极容易发生死锁现象

             参考问题2， 多表的连锁反应极容易造成死锁。特别要碰上多用户并发更新一个表，或触发器所使用的某个代码或存储过程处理速度时间比较长时。

       问题4: 触发链条中，对象失效造成的断裂

            因为DDL操作，造成触发器或存储过程之类失效，而这个失效可能刚好是某个 触发器链条或业务链条的一部分。没有即时恢复或在失效

         其间已有业务处理。这些对你的数据正确性是致命的，由此可能引发一系列问题。

就这几点就已经足够让我对它敬而远之了。 建议对触发器不到万不得已，不要使用它，图一时之快，最后只会伤到自己。

MAIL:xcl_168@aliyun.com

Blog:http://blog.csdn.net/xcl168