触发器可以说是数据库中的常用工具，不过，这个功能是否被合理利用，也在一定程度上影响了最终成品的各方面性能。
要想把说明触发器的适用范围，就得先说说触发器本身具有哪些特点：
各种DBMS实现不同的触发器语法，方言之间的差异很大，表达能力上也不尽相同。触发器是对于一张表的监视，从属于某一张表（一个关系），但是被触发时可以作用于其他表。从逻辑上，触发器对于程序员应当是透明的。基于触发器的上述特点，并站在一个软件全局的角度来看，触发器应该保持对于开发人员的透明性，也就是说，开发人员应当始终不需要知道某个触发器正在对业务逻辑产生影响。
最好的做法就是，使用触发器时，避免使其影响业务逻辑本身，曾经在教科书上看到这样一个例子：
有一个学生选课情况表，字段有学号、课程号、平时成绩、考试成绩、总评成绩。需要设计一个触发器，当学生的平时成绩或考试成绩修改时，就自动按照平时成绩20%和考试成绩80%的比例计算出总评成绩。
实际上这应该是个反面教材，这个使用情形就是刚才所说的触发器干涉了业务逻辑。那么为什么不要让触发器干涉业务逻辑呢？
开发人员站在整个数据库的外侧，也就是关注到数据库的外模式，而不关心或无权过问概念模式和内模式，触发器属于概念模式范畴（甚至可能是更低的层次），不需要被开发人员所了解。那么，触发器对于业务逻辑的干涉将使开发人员对于结果产生困惑，为什么开发人员在看似不完整的数据操作之后（修改了平时成绩或考试成绩后没有修改总评成绩），却得到了完整的结果。这个说法建立在表“充当”外模式使用的前提下。
另一方面，触发器带来了程序员无法控制和了解的业务逻辑，使得软件测试最终变得困难重重，如果有一个BUG出现在触发器中，那么它可能将最后才能被发现，此时已经带来了高额的测试和调试成本。对于数据库管理员也是如此，由于存储过程和触发器处于DBMS三层模型中的不同位置，所以当检查外模式的存储过程的业务逻辑时，也同样会产生不必要的困惑。更严重的情况是，一旦存储过程与相关的触发器单方面进行了改动，最坏的情况可以导致业务崩溃，因为不同层级之间的高耦合带来难以预料的维护上的灾难。
对于上面这个简单的问题，其实使用视图就可以很容易地解决，总评成绩=平时成绩×20%+考试成绩×80%，这样的简单关系通过视图，也不会显著产生效率问题，因为计算不涉及多表。对于涉及许多表而可能影响效率的情况，可以采用存储过程来包装对于平时成绩或者考试成绩的变更，当然对于支持物化视图的DBMS，也可能是不错的选择。
教材上还有一个例子，也针对上面那张表：
设计一个触发器，当删除一条学生的选课记录时，自动在另一张与此表结构一致的备份表中插入这条被删除的记录。
这个例子可以被认为是正确地使用了触发器，它与业务逻辑无关了，即使这个触发器不存在，业务也可以照常进行下去，因为备份表对于开发人员而言实际上也是透明的，只是基于数据可靠性和系统性能考虑而增加的关系，与触发器搭配使用再恰当不过。
另一个使用触发器的场合是统计信息，例如记录用户登录失败的操作、记录用户的操作习惯等等。
但是记得别再一张表上建立太多的触发器哦，否则这张被无数触发器监视起来的表，一旦需要执行DML操作，性能就严重受到影响了。
本文在CC BY-SA（署名-相同方式共享）协议下发布。
