审慎而明智地使用SQL触发器

 

  触发器可以说是数据库中的常用工具,不过,这个功能是否被合理利用,也在一定程度上影响了最终成品的各方面性能。

 

  要想把说明触发器的适用范围,就得先说说触发器本身具有哪些特点:

  • 各种DBMS实现不同的触发器语法,方言之间的差异很大,表达能力上也不尽相同。
  • 触发器是对于一张表的监视,从属于某一张表(一个关系),但是被触发时可以作用于其他表。
  • 从逻辑上,触发器对于程序员应当是透明的。

  基于触发器的上述特点,并站在一个软件全局的角度来看,触发器应该保持对于开发人员的透明性,也就是说,开发人员应当始终不需要知道某个触发器正在对业务逻辑产生影响。

 

  最好的做法就是,使用触发器时,避免使其影响业务逻辑本身,曾经在教科书上看到这样一个例子:

  有一个学生选课情况表,字段有学号、课程号、平时成绩、考试成绩、总评成绩。需要设计一个触发器,当学生的平时成绩或考试成绩修改时,就自动按照平时成绩20%和考试成绩80%的比例计算出总评成绩。

  实际上这应该是个反面教材,这个使用情形就是刚才所说的触发器干涉了业务逻辑。那么为什么不要让触发器干涉业务逻辑呢?

 

  开发人员站在整个数据库的外侧,也就是关注到数据库的外模式,而不关心或无权过问概念模式和内模式,触发器属于概念模式范畴(甚至可能是更低的层次),不需要被开发人员所了解。那么,触发器对于业务逻辑的干涉将使开发人员对于结果产生困惑,为什么开发人员在看似不完整的数据操作之后(修改了平时成绩或考试成绩后没有修改总评成绩),却得到了完整的结果。这个说法建立在表“充当”外模式使用的前提下。

 

  另一方面,触发器带来了程序员无法控制和了解的业务逻辑,使得软件测试最终变得困难重重,如果有一个BUG出现在触发器中,那么它可能将最后才能被发现,此时已经带来了高额的测试和调试成本。对于数据库管理员也是如此,由于存储过程和触发器处于DBMS三层模型中的不同位置,所以当检查外模式的存储过程的业务逻辑时,也同样会产生不必要的困惑。更严重的情况是,一旦存储过程与相关的触发器单方面进行了改动,最坏的情况可以导致业务崩溃,因为不同层级之间的高耦合带来难以预料的维护上的灾难。

 

  对于上面这个简单的问题,其实使用视图就可以很容易地解决,总评成绩=平时成绩×20%+考试成绩×80%,这样的简单关系通过视图,也不会显著产生效率问题,因为计算不涉及多表。对于涉及许多表而可能影响效率的情况,可以采用存储过程来包装对于平时成绩或者考试成绩的变更,当然对于支持物化视图的DBMS,也可能是不错的选择。

 

  教材上还有一个例子,也针对上面那张表:

  设计一个触发器,当删除一条学生的选课记录时,自动在另一张与此表结构一致的备份表中插入这条被删除的记录。

  这个例子可以被认为是正确地使用了触发器,它与业务逻辑无关了,即使这个触发器不存在,业务也可以照常进行下去,因为备份表对于开发人员而言实际上也是透明的,只是基于数据可靠性和系统性能考虑而增加的关系,与触发器搭配使用再恰当不过。

 

  另一个使用触发器的场合是统计信息,例如记录用户登录失败的操作、记录用户的操作习惯等等。

 

  但是记得别再一张表上建立太多的触发器哦,否则这张被无数触发器监视起来的表,一旦需要执行DML操作,性能就严重受到影响了。