减少存储过程对服务器还来的负荷？

Vect0r

我认为这就是业务逻辑层与数据层之间的界限问题了。

复杂的业务逻辑运算应当放在业务逻辑层，充分发挥程序语言的优势，而对数据库的操作应当做成SP放在数据层，缩短与数据库交互造成的时间成本。开发人员要明晰两层之间的界限，明确哪些属于业务逻辑运算哪些属于数据库交互操作，充分发挥二者的优势，提高系统整体性能，并实现多层结构便于系统的维护、迁移和升级。

比如将插入一条数据的SQL写成SP。可以在SP中验证参数的合法性并通过返回或输出参数提交给业务层，业务层再反映回表示层，这样做我觉得是错误的。应该在业务层完成将要插入的参数的合法性检查，然后将合法的参数输入给SP进行插入操作，这样利用了SP被高速缓存，加快SQL处理速度的优势，而避免了在数据层进行业务逻辑判断降低效率，也是清晰的三层（n层）结构使得系统的维护、迁移和升级容易实现、

个人拙见，望指正。

xzh2000

wangyuzhen老兄提到disk I/O與CPU的咚阌昧Φ醛o
有很大的道理哦,
其實在權衡系統性能方面CPU\MEMORY\DISK I/O
是三大指標﹐偶認為相于I/O來講﹐CPU與MEMORY
都是略有盈余的﹐擴充CPU與MEMORY帶來的性能
上極大的提高﹐但擴充DISK帶來的性能提升就極輕
微﹐而且DISK I/O永遠都是一個瓶脛﹐I/O的標標永
遠都要比CPU或MEMORY來得重要一些
從軟件工程上講﹐存儲過程集中于服務器比分散于
客戶端更容易維護與修改

Vect0r

同意，cpu读cache，不明中则读memory，命中装入cache读取，否则读disk,命中则装入memory和cache读。当然这是一种简单的读策略，还有更优化的，但是命中地点更靠近CPU就更快应该是没错的，所以缓存的SP效果有优势。

humanity

对，就是因为当初设计的时候为了便于维护，所以把很多的处理语句都放到了服务器的存储过程中，以至就跟各位讲的一样，由于客户端的的增加而使服务器不堪重负，要知道现在的客户端都是P4或C4的