最近了解了一下数据库触发器，并做一点实际的应用，在翻看其概念的时候，还是本着从理解的角度来学习的，但是，到了实际的应用场景中，还是有一些特别注意的地方的，下面是自己在应用中的几点体会 （1） 针对较为复杂的跨多表的数据业务级别的约束，可以通过触发器来替代大量的后台判断代码，效率较高且便捷。
（2） 如果想通过触发器辅助业务逻辑，不能单着眼于数据库内容的变化来设计触发器，还必须紧密结合业务模型中涉及该表的所有地方，因为很有可能因为不一致的逻辑处理方式导致我们设计的触发器遗漏下一些分支条件！其实，在这种情况下，如果能有更好的方法，不建议使用触发器，因为牵扯到过多的业务逻辑内容的话，会使触发器的设计和编写困难重重，不能充分发挥其便捷高效的优点。
（3） 鉴于触发器在实际运行的时候，是被包含在一个数据库事务中的，所以我们在编写了完整的处理分支后，就可以完全信赖它的执行，大量并发情况下，数据库会自动处理好对各事务的操作，不用担心触发器的性能和正确性。
（4） 在同一个事务中的不同执行语句，如果后面语句中的操作触发了相应表的触发器，则在触发器内可以查看前面语句执行后的结果列表的内容，所以，在使用触发器的时候，对事物中多条语句的操作的顺序是要考虑清楚的。
（5） 如果我们使用触发器+数据表的形式来对数据进行一些统计性的操作的时候，我们在保证触发器逻辑完整性的前提下，最好能通过数据库任务的方式来定时进行检查，因为触发器对于一个用程序的操作都能有相应的处理，但对于人为的数据库操作有时却是无能为力的，所以，为了避免这样的错误发生，有必要对统计结果做定期的校验，保证数据的正确性，当然，如果可以，尽量不要使用这种方法，但在一些个性化项目中，因为一些特别的原因，可能会有所应用。
（6） 我们可以间接地通过更新数据表的方式来调试触发器，当然，也可以通过在触发器中添加一些“特殊的日志性质的更新语句”来辅助我们的调试。
最后再说一句，所谓“好钢用在刀刃上”，触发器在一些特殊的应用情况下，会极大地简化我们的开发工作量，并提升处理效率，但是它并使万能的，也不是适用于各种应用环境，所以我们使用的时候，一定要慎重，更要权衡利弊。

评论 (0) All

登陆 还没注册？