大型系统必须得要存储过程和触发器吗？
2012-01-19 17:47:05   来源：   点击：

8 个答案

• 答案 1：

  我们先要弄清楚二个问题：1.什么是大型系统？2.你讨论的是什么领域的应用，可以大致分为二种：互联网、企业内部接下来给你举一些例子：1.SAP、peopleSoft、ERP等企业级别应用一般情况下，会使用存储过程和触发器，减少开发成本，毕竟其业务逻辑修改频繁，而且为通用，很多时候会把一些业务逻辑编写成存储过程，像Oracle会写成包，比存储过程更强大。另外一个原因是服务器的负载是可控，也即系统的访问人数首先是可控的，没有那么大，而且这些数据又非常关键，为此往往使用的设备也比较好，多用存储柜子支撑数据库2.另外一类互联网行业的比如淘宝、知呼、微博等，数据库的压力是非常大的，也往往会最容易成为瓶颈，而且多用PC服务器支撑，用户量的增速是不可控的，同时在线访问的用户量也是不可控的，为此肯定会把业务逻辑放到其他语言的代码层，而且可以借助一些LVS等类型软硬件做负载均衡，以及平滑增减Web层的服务器，从而达到线性的增减而支持大规模的访问.所以不管你的这个系统是否庞大，首先要分业务支持的对象，系统最可能容易出现瓶颈的地方在那？当然也不是说互联网行业的应用就绝对不用存储过程，这个也不对，曾在阿里做的Oracle迁移MySQL系统确实用了，因为历史的原因，另外还有一些新系统也有用，比如晚上进行定期的数据统计的一些操作，不过有量上的控制。存储过程是好东西，要分场景，分业务类型来用就可以把握好。

• 答案 2：

  存贮过程：可以使用，但不要滥用；触发器：建议能不用就不用，触发器做为下下策之备选方案。

• 答案 3：

  企业级的系统可以用，互联网系统还是尽量少用

• 答案 4：

  同意@方圆的观点，我们的项目中有使用MySQL的存储过程，我一直都想把这个存储过程去掉。

• 答案 5：

  不是说必须得用，原则是视情况而定，不要滥用。存储过程还可以，触发器尽量少用会影响执行效率，特别是对于高频率大量更新的table而言。

• 答案 6：

  可以用,如果你很明确自己的容量和性能,很熟悉存储过程的开发.说点其他的:1. 随着海量的数据增长,高并发的系统,数据库慢慢转化为仅仅作为数据的容器. 如果你的数据库存在瓶颈,存储器,触发器这些都没用了. 2. 从web层扩展是很容易的.所以把计算留给web层吧.

• 答案 7：

  如果用的是MS SQL的话，用存储过程吧，特别是在事务处理的时候触发器建议少用，不然有时出了问题都不知道怎么回事

• 答案 8：

  我其实觉得是存储过程和触发器，特别是在逻辑复杂，代码多时 难以做日志，难以维护，每一个程序员都想将它干掉而后快，这才是根本吧，如果它具备维护简便，容易做日志等,跟代码都没区别了，大家也就没啥疑问了，请DBA跳出来普及下，这种的维护，做日志，方便吗?