项目经验----触发器要谨慎使用

      在一中考评系统项目中，为了使数据保留，删除数据没有使用delete，而采用的是在数据表中加一个字段，存在为‘1’，不存在为‘0’。

    刚刚用户打电话过来，说：不知道数据库中的数据怎么就被删除了，他们没做什么操作；他们直接将数据库中不可用字段改为‘1’也不行。后来我测试一下，我删除对应的系列信息，然后想将不可用字段改为‘1’，无论使用sql语句，还是直接更改记录的不可用字段都无济于事。

        

       触发器编写的代码是：

        

        从触发器执行代码可以看，只要系列有更新操作，就会执行删除系列的操作，所以只要系列信息isUsed字段变为0，就无法更改为1.

       

    灵活地使用触发器可以方便我们实现业务逻辑，从而避免应用程序编码。但是在一个高并发的表上尽量避免创建过多的触发器。

    对于触发器，很多人认为不要使用，主要的原因是触发器不好控制和触发器影响性能。在这里我做一个总结，触发器作为大型数据库的组成部分，可以代替应用程序编码实现复杂的业务逻辑。它的一些功能是其他方法无法代替的，特别是它作为数据库约束的补充，所能进行的业务规则的约束，以及在跟踪和同步中所能起到的作用。

    触发器确实不好控制，这是因为：

    触发器实现的是在表操作的同时，自动进行操作或者控制，在写触发器代码时必须考虑其特殊性。

    必须限定触发器影响的记录，不能扩大。

    写触发器必须考虑性能，因为其自动性。如果触发器性能不好，则可能拖垮一个系统。

     必须考虑一次操作多条记录的情况，除非保证一次只操作一条记录，一般不能用变量暂存虚表的数据，否则就可能出现在批量操作情况下，触发器只处理最后一条记录的情况，这类错误可以说是触发器最常见的错误之一。

     必须注意递归和嵌套触发器，因为触发器往往需要修改其他或者本表数据来实现其功能，这里的修改数据往往能再次触发触发器，这时就必须保证其嵌套或者递归过程不是无限的，不会造成死循环，DB2对触发器的嵌套层数有最多16层的限制。

    触发器不好调试，比起一般的存储过程，触发器是在修改数据过程中触发，调试难度更大。调试过程必须考虑所有情况，比如空表插入数据、已有数据插入新数据、一次插入多行数据、修改一条数据、修改多条数据、一次删除多条数据、影响0行的修改或者删除语句等等。

    触发器不好控制，这就要求我们在决定是否使用触发器的时候需要非常谨慎。个人认为，对于约束功能，如果可以用其他数据库方法实现，比如唯一约束、外键约束、规则约束、不可空约束，那么就不要用触发器，触发器只用来完成这些方法实现不了的约束。对于可以用触发器完成的跟踪、同步功能，则要考虑是否必要，必要的时候才用。而对于特定业务需求实现的触发器，则需要与应用编程实现的优劣进行比较而做选择。