在web网站中大量采用存储过程性能讨论

qingyun

原帖由 horizon 于 2010-6-30 14:23 发表
用存储过程移植会出现大问题,可能要重写存储过程也说不定
但应用程序改动会少

用存储过程移植会大大方便；
  1.大部分系统，前台可能，今天用java，明天用c#,后天用php，或者是多种前台程序混合成一个系统；但是数据库不会轻易变；
在这种情况下，如果业务实现都用存储过程实现，那么移植只是修改一些外围的调用程序，而且就算这些前台开发者的水平烂，
但是存储过程逻辑严谨的话，不会产生异常的逻辑数据；

  2.存储过程，能够被任何前台语言调用，能够在任何操作系统下使用；


  3. 存储过程修改很方便，不用发布，就是脚本重新编译下而已； 现在不是流行动态脚本语言吗？ 存储过程不就达到这个效果吗；


4.先不考虑运行效率；光开发效率来说，存储过程开发速度最快，因为只要是开发人员，是人都懂SQL, 对于oracle,PLSQL很容易学的，理论上一天就能学会；
  而那么多的前台语言，要深入进去，那个不需要3年5载； 而存储过程写的很好的话，半年一年就很强了；


5.不要把写复杂SQL，写存储过程当做是DBA的事情，放眼望去，95%的人都是做开发的，单纯的做DBA的人很少，而且时代发展，就算是强人DBA，必然有很强的开发能力；
就像牛顿，物理上取得了很大的成就，必然有很强的数学能力做基础。
是人都会写SQL， 不会写SQL还能做开发，尤其是面向数据库为主的应用系统；
  凡是资深的开发人员，一般都会有某一两门很擅长的前台开发语言技能；但都不会缺少最基本的技能，就是很强的SQL开发能力，如果SQL很强，存储过程能力自然也会很强；

[ 本帖最后由 qingyun 于 2011-1-7 23:12 编辑 ]

lht821008

使用存储过程还是sql，这个要看具体的业务需求，适合的才好
thomas kyte建议建议去看看

monkeyai

这个其实没太多争论余地吧。

如果是典型的WEB引用，一般没必要用存储过程，OLTP类型的事务一般都很简单，涉及数据量小，而且前端用户基本都是通过WEB界面操作，不可能直接输SQL语句吧，至于所谓绑定变量以复用SQL语句之类问题，应该可以在应用层实现，要是前端应用都是硬编码那怎么也没办法的；

如果是OLAP或者DW这类大数据量处理，那PL/SQL用的就比较多了。因为1、可能有比较复杂的处理，单条SQL逻辑实现不了；2、对于大数据量，直接用单挑语句可能超出系统硬件能力，搞点回滚段过旧之类问题出来；

Coast_lichao

合适的事物用在合适的地方合适的时间，哈哈。

xiao222

小弟也关注一下.

paulxu2002

mark，学习了

1060406004020

本人总结出以下几点，是存储过程比sql要好的地方
1、        存储过程可以用流语句编写，具有很大的灵活性，如果业务逻辑要完成一个很复杂的数据库操作，那么使用存储过程，你只需要在应用端输入参数直接调用就行，那岂不是很方便？但是你要通过sql的话，那就不知道要定义多少个String了，然后通过jdbc与数据库进行通讯。
2、        使用存储过程可以降低网络的通信量，当你使用存储过程时，jdbc完成的只是对存储过程的调用，而使用sql语句时，每条操作语句都要和数据库进行一次通讯，那不但会增加应用服务器的压力，而且大大增加了网络通讯量。
3、        在运行存储过程之前，数据库已经对存储过程进行了预编译，并给出了优化方案。所以他会改善了sql语句的性能
4、        存储过程可以保证数据的安全性和完整性。安全性就是使没有权限的用户间接地存取数据，完整性就是可以使一组相关的动作一起发生，这个有点类似于事物的概念。

catchwo

看用户量啦,上十万百万千万用户量的话,你的数据库顶不住地,计算能力消耗太大,只能通过web服务去分散压力

developerm

学习了，

dnpy

这个问题争论好像是很常有的```开发人员与数据架构人员。
论执行效力来说，逻辑让页面来执行会快一点，
但数据架构师通常认为不能浪费了数据库的强大能力。