用触发器,来做ERP软件里的大部分业务逻辑,这种方案好不好?(大家帮忙,非常急,非常重要!!!)

Question

做几年ERP了,很少用到触发器.最进要新搞1个ERP项目,公司项目经理建议,以后项目里的大部分业务逻辑,都要用触发器来实现.前台界面只要实现,CRUD就可以了.请问,大,中型ERP项目,用触发器来实现,大部分业务逻辑这种做法,可行吗?又或者可行,但算不算1种比较好的做法呢?大家1般都是怎么做的?谢谢!

Answer 1

自己先回答:1,做C/S,1般把业务逻辑做在存储过程里.
2,做B/S,我基本全部做在前台,非常复杂的才放到存储过程里.

Answer 2

估计使用这种方式你会晕死.1. 不利于移植
2. 你得要专门且精通数据库的DBA来维护和管理, 否则数据库可能会被性能不好的触发器搞死, 而你的程序却得不到有用的信息, 不好找问题3. 你需要一套完善的管理方案, 且非常清楚触发器嵌套/递归的结果是什么, 并且有解决方案
   因为很可能会出现你改A表数据, 触发器自动维护B表, B表触发器自动维护C表, 而C表可能又会更新A表的状态表示处理完成了, 一不小心这就是个死循环.
   再考虑数据一致性, 像这种多个表递归下去, 如果要保证数据一致性, 则必须一个大的事务, 否则中间出错无法回滚, 而大事务是最容易产生堵塞和死锁的.
   再考虑这里的错误处理, 如果报一个错误, 你能知道错误点在那吗?
   再考虑业务的正确性, 如果用户告诉你输入某个数据库, 出来的结果不正确, 你能找出是那个触发器处理错了吗? 

Answer 3

呵呵，这么大的系统，尽量少用触发器等东西这么复杂的东西，稍有不慎，就乱套了速度，恐怕要奇慢无比。当然如果给小公司做的ERP数据量小的话，倒还可以，要是给大公司或集团使用，就麻烦了

Answer 4

使用触发器，所有业务逻辑只能靠那dba来书写，那dba可是整个系统的核心哦，以后调试，修改有的他忙了以前左的业务恨少用触发器，复杂点的用存储过程，一般的还是通过hql来写

Answer 5

邹老大说的很对啊，触发器可控性太差，无论在开发，调试，实际应用中都是，ERP数据逻辑相对复杂，大量采用触发器是非常危险的做法。我们一般都是少用，并尽量不用。