触发器具有强大的约束能力，为什么我们老师还说尽量少用，能不用则不用？过度使用会有什么不好的后果吗？请解释得通俗一点，我是一个初学者，太专业化的术语搞不懂，谢谢啦。
------解决思路----------------------
主要还是不好被跟踪，也不容易被注意到。
特别在团队项目开发中，如果你接手别人的项目，对项目或者业务不是很清楚的情况下，如果之前的系统触发器比较多。没有注意到，而忽略的话。会给熟悉系统增加很大的难度。。。
------解决思路----------------------
Copy...
那是从性能上考虑的, 触发器对表的每一行都会处理一个事务, 长时间的增删改操作,小数据量没啥问题 ,数据多了就得要优化了
假如你是多人使用的﹐触发器最好少用﹐因为﹐如果两个人同时触发了触发程序
那如何办？
假如没有应用服务器,那么DB服务器的负担将加重.
假如要进行数据库的迁移,比方说从SQL Server的数据库迁移到Oracle的话.
那么大量的触发器和存储过程将给你带来很多的麻烦.
因为各个DBMS的语法及处理方式皆不同.
------解决思路----------------------
触发器的作业主要是保证数据的一致性和某些安全性。
你想想，如果有个触发器，对于每个数据插入，要更新另外一个表。
一旦你插入的数据有百万、千万甚至更多，那么就要调用百万、千万次的触发器。你幻想以下就知道开销了。
同时，就如bean_sql说的，在数据库的过程中，触发器也容易导致一些无法想象的后果。所以要慎用。
------解决思路----------------------
性能与维护
------解决思路----------------------
++
4楼的回答言简意赅了！
1.性能，会对大数据量操作构成影响，2#说得很明确了；
2.维护，在数据因为触发器报错引起问题时，需要花时间去维护，在不知有触发器的前提下，将很难查找原因。
------解决思路----------------------
个人意见：
1、实际触发器对性能有影响是误解，如果业务要求需要多表操作，而且是事务性的，那不用触发器也只能是个事务操作，本质上事务的大小和工作量是一样的，都是由业务决定的。
2、我也支持触发器慎用，主要原因是合理的触发器编写对设计者和编写者的要求很高，必须比较全面的分析相关业务，同时全面了解触发器工作原理。也就是说写出的触发器要求在业务上考虑全面，在技术上作到最好，才能不影响业务和性能。
3、触发器确实不容易被注意，给后期维护带来困难。
------解决思路----------------------
我给出使用触发器的建议有如下几个
（1）触发器来实现功能比较隐蔽(对于新手+管理比较差的项目来说尤其如此)。比较差的项目最多有个表结构说明，触发器，存贮过程等其他数据库对象根本没体现在文档。项目的代码你能看懂，但少了那个触发器或存储过程就会业务不完整。所以会造成新人理解到的处理流程是不完整的。
（2） 业务功能避免使用触发器，但也有较适合的地儿用。比如：做业务数据日志跟踪功能。某一业务表数据一变化
我们需要在日志表做记录。这个情况较适合用，但必要时得考虑上面大家提到的性能问题
(3) 触发器约束功能的话，其实也没必要。它确实可以完成复杂约束，但业务规则放到代码业务模块处理更正常些。数据的简单格式检测可以靠字段类型、长度、default not null 等完成