34,576
社区成员
发帖
与我相关
我的任务
分享大家对存贮过程有什么看法
目前流行的三层结构中，不管是com+还是j2ee似乎都不鼓励大量使用存贮过程，各位认为使用存贮过程和使用component相比，性能是不是会更好一点呢？
...全文
请发表友善的回复…
发表回复
flowerofwind 2001-11-22
- 打赏
- 举报
我觉得使用procedure灵活性和可移植性较差
昵称被占用了 2001-11-22
- 打赏
- 举报
学习!
icevi 2001-11-22
- 打赏
- 举报
同意flowerofwind(现实很残酷)和mycode(不写代码)。
我的意见是两层结构时能用就用，毕竟还是很好用的。
三层结构时能不用就不用，不到万不得已再用。
若要考虑可移植性，干脆不用，不好移植的。
个人观点，仅供参考：）
我的意见是两层结构时能用就用，毕竟还是很好用的。
三层结构时能不用就不用，不到万不得已再用。
若要考虑可移植性，干脆不用，不好移植的。
个人观点，仅供参考：）
bend 2001-11-22
- 打赏
- 举报
我觉得应该尽量发挥数据库服务器的性能，如果你采用的数据库系统支持存储过程，应该使用存储过程。至于组件复用的问题，应该根据不同的情况分别对待，不能够指望编好一套组件后，靠它们包打天下——不论什么数据库系统都适应，而不需要修改任何组件代码，这好像违背了组件的本意——接口和实现分离。
KingSunSha 2001-11-22
- 打赏
- 举报
存储过程的可移植性确实非常差, 几个主要的RDBMS SQL的语法相差太大. 但灵活性,可重用性并不差,ORACLE的包其实也可以认为是一种早期的分层概念.
我的想法是:
1. 用过程来处理基本表读写操作(基本上不在外部直接处理表)
2. 用中间层来处理业务逻辑
3. 前台只处理显示和接受输入
我的想法是:
1. 用过程来处理基本表读写操作(基本上不在外部直接处理表)
2. 用中间层来处理业务逻辑
3. 前台只处理显示和接受输入
seeit 2001-11-22
- 打赏
- 举报
尽量少用（尤其是在程序里），要和整套软件保持一致。学学软件工程吧
mycode 2001-11-22
- 打赏
- 举报
如果你开发的系统,只能提供自己的系统使用,那你可以采用存储过程.
当你的系统还想提供给别的系统调用时,组件的重用性的好处,就体现出来了.
存储过程,个人认为是在三层结构没有大量使用时的一种替代解决方案.
当你的系统还想提供给别的系统调用时,组件的重用性的好处,就体现出来了.
存储过程,个人认为是在三层结构没有大量使用时的一种替代解决方案.
Lymanlu 2001-11-21
- 打赏
- 举报
也不是啦！我是支持使用组件的，这样可以增加代码的重用性，减少再开发的难度！对于一个程序员来说是有好处的！
itroad 2001-11-21
- 打赏
- 举报
我建议能用存储过程的地方，尽量使用。
好处吗。。。
难道你开发出来的程序，需要经常改变dbms?!
好处吗。。。
难道你开发出来的程序，需要经常改变dbms?!
progame 2001-11-21
- 打赏
- 举报
嗯，听君一席话，胜过坐轮椅啊
于是我摇着轮椅走掉了.........
于是我摇着轮椅走掉了.........
progame 2001-11-21
- 打赏
- 举报
推个轮椅过来旁听中。。。。。
'/*没接触三层结构啊，所以现在偏爱存储过程：（
'/*没接触三层结构啊，所以现在偏爱存储过程：（
KingSunSha 2001-11-21
- 打赏
- 举报
纯粹就性能来说，存贮过程肯定要好过外部的调用。
三层结构中不鼓励大量使用存贮过程的原因主要不是考虑性能的问题，更多的是考虑component的通用性、可移植性以及负载平衡等因素。
三层结构中不鼓励大量使用存贮过程的原因主要不是考虑性能的问题，更多的是考虑component的通用性、可移植性以及负载平衡等因素。
