以下是内部的关于触发器和存储过程的邮件沟通内容，反映了对触发器和存储过程的支持和反对双方的观点。
---------------------------------------------------------------------------------
部分观点和你不同。你说的在项目上的坑，不能甩锅触发器。
1，触发器和java代码没有本质的区别，不同的语言而已。用和不用，数据库该做的事情1点没少，一个在java程序里发起sql，一个在触发器执行。所以触发器不会给数据库带来任何性能和并发问题
2，触发器和存储过程性能是高的，这是其主要的优势所在，他是预编译的，而且省掉了和数据库建立连接和通讯的成本
3、触发器和存储过程不会比写得很烂的java代码带来的副作用更大。
4、触发器和存储过程也是代码的一部分。从这个意义上讲，不用触发器，同样存在升级的问题。这不是触发器的问题，是开发管理问题。
使用触发器和存储过程也有缺点：
1，将业务逻辑打散了，一部分在java代码，一部分在数据库。增加了开发管理的难度，这是它的弊端。
2，不是面向对象的，是面向过程的。
3、数据库迁移变复杂了。
任何技术都是有利有弊，综合比较，我认为使用触发器和存储过程是有他的适用场景。我以前也反对使用触发器和存储过程，现在不一样了。
From: ▓▓▓▓▓▓▓▓▓▓
Sent: Thursday, December 26, 2019 11:44 PM
To: ▓▓▓▓▓▓▓▓▓
Subject: 回复: 关于数据修改日志的一个触发器实现方案
存储过程、触发器 ，我们不提倡，更不建议在数据库上做任何触发器操作，触发器会给数据库本身带来性能问题，并发大了甚至会拖垮数据库，同时后期的运维升级的人员，如果没有全面了解相关触发器，可能会出现运维障碍，曾经在多个项目上踩过坑，包括xx、xx的资金等采用的触发器也都取消了。
大型集团，高并发的应用，数据库越简单约好。
建议尽量使用程序替代数据库触发器。数据库的意义，目前就是存储。数据库的作用越来越低了，弹性配置，资源配置都在Web端。数据库就仅仅是执行存储而异。
