数据库探讨-触发器
使用了一段时间数据库，对视图、函数及存储过程等的使用都比较流畅，唯独触发器总是感觉怪怪的，总有些事情放不下似的。年底了，应该探究一下这个问题了。在网上简单地浏览了一下，大面上的评论几乎都如出一辙，内容也跟一些老程序员挂在嘴边的评论差不多，都很对但参考价值有限。在这里我尝试性地在一个新的角度去做一下分析。
触发器：（trigger）是一个特殊的存储过程，它的执行不是由程序调用，也不是手工启动，而是由事件来触发。这是触发器的定义，那数据库的灵魂是什么？是“事件触发”，这是触发器区别于其他数据库元素的根本特点，也是它在使用人群中备受器重和非议的根源。
有编程经验的人知道，触发一段程序执行的本质是相同的——“调用”。在我们使用C、Java等高级语言进行编程时，我们经常会这样做：在程序段的首部进行安全性检查代码；在尾部写些善后的处理代码。这些甚至已经习惯到了不用去思考。但在数据库操作中，巨大的操作差异很容易让我们忽略了这种现象，只有在编写存储过程和函数的时候才仿佛找到了一点感觉。
我们可以使用存储过程的方式处理复杂的数据库更新操作，在更新语句之前添加校验代码，在更新语句之后添加一些必要的协调性处理的代码。但这些都有一个隐含的前提：用户是使用存储过程来更新数据。使用过数据库的人了解，主流的DBMS为使用者提供的数据修改途径是很“丰富”的。之所以会出现这样的矛盾，根本原因是执行代码的内聚程度低。这就像一个程序实现校验、更新和善后工作同使用三个程序分别独立地实现校验、更新和善后工作的区别。而这种矛盾的客观性及重要性就是触发器产生的原动力。
个人观点认为：触发器是对数据库自身更新的原子语句的扩充。通过触发时机的区别，给使用者提供了一个可选择地向前或向后扩充数据库更新过程的接口。扩充后的更新过程将它们和原有的数据更新过程凝聚成一个整体，进而渗透到所有的数据库操作中，使程序的内聚程度达到一个质的提高。
当前很多人把触发器当成双刃剑甚至视如猛虎，理由最多的是难以控制。但我认为，我们只要遵循着触发器的本来，深入体会它的使命和价值，它将会使我们无往不利的好伙伴，而不是谣传的那样怪异。
