【讨论】关于数据层用不用存储过程封装的问题？

alive501

我們的ERP系統　邏輯全部用PLSQL寫的，新增刪除更改記錄也用SP實現　IFS

顾而不问

大项目里把SQL干到页面里完全不可行，维护成本太高了。
而且每个程序员的风格和水平不一样，那SQL写的五花八门的，维护起来会死人的。
一般的项目里（非银行和电信），通常情况下返回的结果集数量都不会很大。效率基本上不成问题，封装到过程里没啥大问题。

killkill_shadow

先不说性能和逻辑究竟应该放在应用层还是plsql过程中这两个问题，我先说说近日遇到的一个问题：

近日发现数据库的CPU占用很高，用AWR找出Top SQL然后开始调优，但是这条语句有一个
dbms_lob.instr( userid_list , userid )
开发商把userid串接成一个字符串放在userid_list里面，userid_list是clob类型读取时默认触发 direct path read，再查I/O发现磁盘每秒读取60~70 MB，修改存储属性，让clob也能缓存在内存中，但是该死dbms_lob.instr( userid_list , userid )导致了一张一万多行的表扫描4次，一万多行不多，问题是每行都起码有一个clob(8k)，估计CPU就是在这里面耗完的。
联系开发商改应用，估计拖到猴年马月，自己改又没有源代码，建索引 dbms_lob.instr( userid_list , userid ) 怎么弄？其他涉及的字段选择性及其差，都是状态字段。
现在只能说俺们机器和存储比较好，硬撑这个SQL。

如果对外只是提供过程作为接口，那好办，方法多了，废掉这个表，把userid_list拆开按照范式做，建立相应的索引，用userid查，那根本就不是什么难调的SQL；不改表，在这个表加触发器，增删改都修改另一个范式的 userids 表，再改SQL把dbms_lob.instr( userid_list , userid ) 改成搜索遵守范式的表；再不行，上全文索引，把dbms_lob.instr( userid_list , userid )改成 contains(userid_list , userid)；
方法多的是，把过程或者SQL放在数据库一级关键是实现了接口与具体实现的分离，深奥一点的说法是，用接口把调用和具体实现隔离，GOF的设计模式中很多都是在实现变与不变的分离，策略模式，模板方法模式，工厂模式等等就是最好的例子。

再说远一点，贪方便把SQL放在页面或者应用中开发速度是快，ASP年代MS也是这么想的，自从JSP崛起，以及ASP.net哪一个不是搞分层？
层与层之间的调用哪个不是通过接口隔开，不用接口隔开就和一堆类调用另一堆那样，最后变成一碗兰州拉面一样。

说回刚才那件事，现在的状况就是应用对于DBA来说就是一个黑盒，接口就是那条SQL语句，你不能动，只能动数据的一些存储结构，例如索引，表类型等，处处受限。

whw_0501

项目一般用MVC模式,我们一般都会写一个数据库访问接口公共类,平常的SQL语句我们都放在service层,对于过程来讲,我们也放在service层,由service层调用数据访问接口

廖猫猫

java项目中，还有一种比较常用到的是：SQL语句放在DAO层，service调用DAO

风铃中の鬼

简单过了一遍帖子- -。。。我怎么觉得有人把一套完整的系统给想象成只由页面和数据库组成的了呢。。。。。

killkill_shadow

原帖由 风铃中の鬼 于 2010-7-29 09:02 发表
简单过了一遍帖子- -。。。我怎么觉得有人把一套完整的系统给想象成只由页面和数据库组成的了呢。。。。。

引用一下当年我毕业设计时评委老师的一句话，“你这个不就是给数据库加个壳吗”

PS：当年我们专业10个人有9个是做信息系统，9个人中没有一个不用数据库的，老师都看不耐烦才有上面的感叹。幸好我做的是单机软件，剑走偏锋，拿了个校优。

newkid

原帖由 风铃中の鬼 于 2010-7-29 09:02 发表
简单过了一遍帖子- -。。。我怎么觉得有人把一套完整的系统给想象成只由页面和数据库组成的了呢。。。。。

不管你系统分几层，和数据处理相关的逻辑就应该在数据库里完成。

xqmei

Sometimes, we need to consider: using store procedure as the only interface may push the work load from application servers to DB server.
So need to check the pros and cons ahead for different requests. Nothing is absolutely right or wrong.

newkid

原帖由 xqmei 于 2010-7-30 02:50 发表
Sometimes, we need to consider: using store procedure as the only interface may push the work load from application servers to DB server.
So need to check the pros and cons ahead for different requests. Nothing is absolutely right or wrong.

在大部分情况下，PLSQL存储过程只是SQL的轻量级包装，大部分工作量还是落在SQL. 就算你把存储过程做的事拿到数据库之外完成，SQL还是那些SQL(甚至更烂，如果该程序员不熟悉SQL的话)，不仅如此，同一个事务还要和数据库多次交互，而不是仅仅一次存储过程调用，因此想给数据库减负的初衷，往往适得其反。