关于存储过程的使用,如何适度的在使用存储过程?(200分)

子陵

Unregistered / Unconfirmed
GUEST, unregistred user!
存储过程到底是用的越多越好,还是在客户端处理好,如何适度的处理?
目前的数据库服务器处理存储过程的方式,对使用存储过程的要求?
 
如果有连续的对数据库进行频繁操作,则将需要的内容作为参数传入到过程中,使用过程。
有的系统在设计时要求所有对数据库的操作必须在后台运行,则你只能使用存储过程。

使用存储过程的主要效益:
1 减少网络通讯量
2 由数据库自身控制事务处理
3 保证数据库的安全性
 
如果考虑到可移植性, 就要少用存储过程...尤其是可能在多种数据库平台上使用
 
通过对查询分析器的观察可以看出存储过程提高性能最大的是节省了CPU时间,而对I/O时间并无
大的影响
对于DBA来说,存储过程相当有用
但对于程序员来说,除非有很复杂的牵涉到计算的SQL语句(计算量大)否则都没什么必要用到存储
过程,减少网络通讯量也是基于此(无需传递所需数据到客户端,直接在服务器端完成计算)
 
若是SQL SERVER,你可以参考它的在线帮助文档.
 
我认为业务处理都用存储过程来实现比较好。这样当业务发生变化时,只需要修改存储
过程,而不需要重新对程序进行编译。有利于软件的维护。我们现在的开发方式基本都
是这样的。
 
关注,并学习。
我也认为存储过程不宜过多使用,否则系统的调试、维护够你麻烦。
 
这要看你用的一个数据库或N个数据库
若想跨平台, 则少用存储过程, 这样也可以减少开发者的难度
若不考虑跨平台, 则能用就用
 
为什么非要把程序员和DBA的工作划分的这么清楚?而且说到底存储过程也不能说是DBA的
工作范畴。
感觉上用存储过程才是适合于跨数据库平台的一种方式,不同的数据库对应于不同的存储
过程代码。至于运行软件平台,你只需要确认所连接的数据库种类是什么,然后在软件的
INI(举例)中以不同的方式来调用存储过程就可以了。

不用存储过程,如果你的代码中使用了某种数据库的SQL扩展,那在跨平台时你只会更惨!
 
需要进行复杂的数据处理,且计较系统运行效率的用存储过程,其他的用query。
 
將存儲過程用來實現業務規則有許多成功的案例,有許多公司就用這種開發方法。
包括國外的一些公司。總之這是一種非常不錯的方法。但要考慮到DBMS的負荷﹐不要太
重。凡事都是這樣﹐物極必反的。
我以前的公司全部使用存儲過程﹐而我現在公司則一點也不用。各有優點﹐不好一刀
切。應該互補﹐如何有效實現功能﹐簡化開發才是關鍵。
 
我很少用存储过程、触发器,都是靠写程序,反正也不麻烦
 
感觉没有结果,有高手好好总结一下!
 
存储过程好,存储过程好。
 
用存储过程速度上比较快
 
其实从更深层的意义上讲,这是数据库分层设计的一种模型,VIEW代表表现层,PROC代表
业务逻辑层,而物理表代表物理存储层,特别对于大型项目来说,数据库分层设计是很有
价值的。如果有兴趣,大家可以看看与设计模式有关的一些书。
 
两次同意army jiang .补充:在实际经验中,我发现存储过程还有一个用处,对于多用户环境,可以
将并行操作通过DBMS转为串行操作.不必考虑一些并发锁定问题.其中例子之一,如果几个用户
同时操作某表,欲自动产生某号码,则用存储过程可保证号码一定是连续不重复的.(当然,可以
使用DBMS的具有"IDENTITY"属性的字段,不过有时实在用起来不方便,比如,你只能Insert 之后
才可以用SELECT VAR1=@@IDENTITY之类的语句.)//SQL Server.
另外,如果缺乏经验,您可以先不用存储过程,整个程序调通之后,再改为stored procedure进行优化.
(好象不符合软件工程? NO,谁的程序是一气呵成的?)
对于工作量小的Server,喜不喜欢,优不优化成stored Procedure并不重要.反之,一定不能因为
"可移植性"而牺牲性能,速度.正如armyjiang 第二次所言,Use stored procedure"可移植性"
从总体而言反而是很好的.

 
谢谢大家
 
我觉得存储过程的好处很多,
如果你是存储过程的编写和调试高手,能用存储过程的地方尽量用存储过程。
我以前不喜欢用存储过程,总是把业务处理放在代码中来实现,
但是这莫做的最大的坏处就是一旦当这个业务的处理流程发生变化你就必须去更新客户端程序!
这样的工作量比较大,因为你要重新分发客户端程序!
要是把业务逻辑用存储过程来实现则可以避免这个问题。
还有从“层”的角度来考虑,存储过程更像一个“中间层”,他封装业务逻辑,
客户端只需要传入必要的参数,其他的完全不需要考虑,然后得到返回的结果
即可。这样从编程上讲也有利于团队的合作。

 
顶部