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

wwhzm

用到恰到好处便可，没有绝对好坏之分，存在即是合理的。

jack22220613

看完一遍不容易啊

jack22220613

原帖由 newkid 于 2010-7-2 00:48 发表


其他语言就没有切换了？PLSQL至少和SQL是在同一台机器上！



放到数据库外实现为什么就没问题？


那我看到一段JAVA也是一头雾水！




全用存储过程问题多在哪里？




分层也可以分到DB里面。"SP肯定不是最优的", 举个实例看看？有可能是你的SP没写好。




“存储过程迁移”？数据才有迁移。如果你是说把程序复制到各个库，不用存储过程难道就不用复制了？应用服务器上也得有程序吧！

“如果业务逻辑变化的时候，怎么弄，改存储过程只有”改就改呗，难道放到外面就不用改。

“然后就是在并发比较高的OLTP，性能是很差的”举个实例。

存储过程的调试并不比其他语言更困难。


你这个只是TABLE层面的API, 就是所谓的TAPI, 好的做法是TOM提倡的XAPI, 即事务级别的API. 事务里面可能有多个SQL, 直接写就是，不必再弄一层表级的API.




应用服务器不是最后也要访问DB? 一个事务如果用到10个SQL, 放到应用服务器也是一样，一个都跑不了，最终压力还是会落到DB.


如果你说的是换数据库，趁早打消这个念头，不管怎么做都是很困难的。TOM的书专门有一节讲到为什么独立于数据库的想法是不现实的。
PLSQL实际上更为“通用”，在任何操作系统的ORACLE都一样运行；所有的开发语言都可调用存储过程。



把所有CRUD都做成存储过程不是办法；存储过程应该以事务为单位。
参数也可以用OBJECT来传递，类似PLSQL的记录类型。
如果你的应用服务器被攻击了，别人可以上传脚本做DML那就很危险。把表的权限都收回，只留下存储过程接口相当安全一些。



如果你允许新旧版本程序一起跑，才有可能把APP逐个更新。

不得不佩服newkid大牛，很能辨，不过也仅仅是辨了而已。

zty5984

学习了 大师们的讨论

心情车站

学习了

orion61

如果改动关键表，存储过程失效，会是一个很麻烦的事，存储过程设计不好，互相关联，更加麻烦，我觉得存储过程不太适合关键业务。

ludal

看了Newid的回复=。=

哈哈

不说绝对的话，要不然大师来了一个个被秒杀

zhoujiongfield

原帖由 orion61 于 2010-12-17 21:32 发表
如果改动关键表，存储过程失效，会是一个很麻烦的事，存储过程设计不好，互相关联，更加麻烦，我觉得存储过程不太适合关键业务。

改动了表，java程序就不需要改了？你这个说的也太片面了。
我以前用过ibatis这个持久层java框架，如果数据库结构改了而映射文件不改，应用都启动不了。

看了这个帖子收益良多

xpchild

我觉得；

1，按照分层的原则，一个大型的scalable的web 2.0项目，目前大都采用的至少三层原则，但这并不是说层越多越好，因为交互也是有开销的，但是一个层面就让它解决分内的事情，这样会比较清晰。
2，在业务量和访问量上去的时候，你会发现数据库往往会成为瓶颈，所以业务的处理就尽量在中间件中，业务逻辑层处理，数据库越简单越好，简单就是最美的。
3，oracle的官方文档，或者tom的书中都说建议使用存储过程，给出的理由是你花了钱，就应该充分的使用oracle的特性。这点明显都点广告的味道。

最后：过多的使用存储过程，把oracle变的异常的庞大，增加了管理成本，不利于scable。

qingyun

原帖由 xpchild 于 2010-12-29 18:38 发表
我觉得；

1，按照分层的原则，一个大型的scalable的web 2.0项目，目前大都采用的至少三层原则，但这并不是说层越多越好，因为交互也是有开销的，但是一个层面就让它解决分内的事情，这样会比较清晰。
2，在业务量和访问量上去的时候，你会发现数据库往往会成为瓶颈，所以业务的处理就尽量在中间件中，业务逻辑层处理，数据库越简单越好，简单就是最美的。
3，oracle的官方文档，或者tom的书中都说建议使用存储过程，给出的理由是你花了钱，就应该充分的使用oracle的特性。这点明显都点广告的味道。

最后：过多的使用存储过程，把oracle变的异常的庞大，增加了管理成本，不利于scable。

2.在业务量和访问量上去的时候，，本质就是 update,insert 一坨坨SQL频繁的提交; 如果写在中间层，用java 动态拼一坨坨字符串，然后一条一条的和DB交互10次；
好“伤”数据库啊 ，这个瞬间大量的java产生的sql字符串，通过jdbc 高速的与数据库交互 ，不如封装层存储过程；减少通讯量；
毕竟PLSQL的引擎是对于SQL的切换内部的；而java与数据库的引擎要比他慢的多；

最后，过多的在中间层是使用一坨坨杂乱如麻的动态字符串SQL，把oracle的SQL变的异常的庞大，出了问题维护麻烦，很难找出那些sql写的有问题；



很多人都觉得，中间层业务服务器，可以很好的分担数据库的压力；
也就是说：本来 数据库 一个人在干活，现在来了N个中间业务服务器，那么就是N+1人在干活；数据库服务器他就只需要干1/(N+1)的事情；
         那是细想一下，可能吗? 中间业务数据库，大部分时候是把一坨坨动态SQL字符串，通过jdbc这样低效的驱动，不停的对  数据库这个人 拼命的要求update之类；

也就是说：如果用存储过程封装，相当于领导(客户端)分配一件事情给你，你做好后提交即可；

   而用中间层动态SQL来封装业务，相当于领导(客户端)分配一件事情的时候，没有直接给你，而是给了几个中层领导；这几个中层领导自己也不会做，而是把这件事分解成很多小事情，
不停的一件件的问你或者要求你去做； 结果本来一件不是很复杂的事情，很快能做完的； 但是经过几个中层一折腾，反而经过了很多手续和过程，导致了中层领导很累，你也跟着很累；

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