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

〇〇

原帖由 killkill_shadow 于 2010-7-29 13:15 发表


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

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

为什么不用现成db工具

killkill_shadow

原帖由 〇〇 于 2010-7-30 05:55 发表

为什么不用现成db工具

1。那时候大学还没有毕业呢，懂的也少。
2。毕业设计要求代码量的，好像是1万行吧。

tom0732

我也偏向用存储过程封闭SQL,维护相当方便.表结构有修改都不用重新编译前台代码.前台就是个用户界面,业务逻辑都放存储过程里面.

sleepinglord

1.不是一定要用存储过程……
2.但坚决不要放页面上！！！难道除了页面就只有数据库吗？

除了安全和什么什么，有些更现实的理由。

考虑一个查询界面，有10个可选的条件框，他可能在任何若干个里填写或者勾选等等。
在我看来，你只能在后台通过拼字符串的办法，他填了哪个，你就把相应逻辑的条件写到where里去（注意这里的逻辑不一定是“xxx = 值”这样的简单逻辑。或许他选了某个框，你的where里要增加相当多的玩意），放空的则不写。请问用存储过程该如何解决这个问题呢？

newkid

刚才已经回了一贴，在存储过程里用动态SQL:
http://www.oracle.com/technology ... -jul/o49asktom.html

我不晓得 ebay 或 taobao 的技术会有多先进。。。
我们的应用都是这种架构  htm/jsp<------------------->web server(java sql语句拼装、存储过程显示调用)<----------jdbc thin/oci------------->db(含少量关键业务存储过程)
html/jsp 这层接受用户输入的查询条件、元数据，
SQL代码是在 web server 中xml 保存的的，
db层有少量的存储过程（关键业务的存储过程 逻辑复杂 频繁修改查询条件）

首先SQL代码在 JSP /php 里拼装这种设计模式早淘汰了，至于它的弊端我就不赘述。
至于全用 SQL代码好还是存储过程好，我的观点是 能用SQL语句实现的就尽量用SQL语句，太多存储过程会加重对 DB的压力，至少 应用的集群比DB的集群性价比要高且技术要求低
当然 存储过程的作用也是显而易见的，我以前做过一个应用，用户查询 工作流数据，接受用户输入的查询条件有 70几个，并且用户经常修改，业务非常复杂， 那个存储过程有 1500多行代码，其中涉及到大量的 动态SQL语句的拼接和 hints 选择，并且客户3天两头修改。我想这个应用SQL语句是很难实现的吧？

[ 本帖最后由 拒绝二流 于 2010-8-8 22:51 编辑 ]

newkid

“太多存储过程会加重对 DB的压力”？压力来自存储过程里的SQL, 你拿出来一点缓解都没有，SQL还是那些SQL(有时候还更糟糕)。

xjg

如果是企业级应用，都没有问题，大家都用存储过程吧，好维护，方便修改

但如果是大并发的WEB应用，很快你就会发现，所有的瓶颈都集中到了数据库服务器上面。

我估计这也是为什么TAOBAO、EBay很少会用存储过程。对他们来说，数据库只是用来持久化的，业务逻辑什么的，都在应用层实现。
只有这样分层，横向扩展才有可能，毕竟DB要横向扩展个几百几千台机器不大可能吧？

newdelete

我们的标准跟你们cto一样，简单的sql，直接通过中间件包装进库，涉及大量业务处理或者大数据量的，用过程。

我觉得挺合理的。

qingyun

原帖由 anran_guojianjun 于 2010-6-30 17:10 发表
业务逻辑比较复杂，优化考虑存储过程，这样可以减少与DB的交换过程。因为我们只要最终结果，中间状态不需要。
单独一个SELECE或UPDATE就没有必要用PROC了。

这个观点我基本同意，如果确定就是仅仅一条update ，那么可以不用存储过程；毕竟 pl/sql 引擎也可能消耗时间的；

但是为了功能扩展，你不知道这个点，以后会不会加入其它语句；所以写个过程更通用些；

这个我觉得还是权衡吧；


我的习惯是：通用重要，效率更重要； 两种权衡吧；
不过即便是一条简单的update语句，我也是倾向于用存储过程；

[ 本帖最后由 qingyun 于 2010-9-20 22:30 编辑 ]