把业务逻辑从存储过程中拿出来

对于业务逻辑放在存储过程中的情况，目前比较有市场的看法是： “不要把业务逻辑放在DB中，除非有性能问题”
日前，我却遇到另外一种情况：
首先说一下业务（简化过的）：
酒店预订系统，酒店是按天计算价格的，酒店合同价格是按时间段的，后录的合同如果时间上与原来的重合，则使用后录合同的价格。
现在的问题是从酒店合同价格计算预订时间段内的价格。主要有三个步骤：
1.分割：把合同价格的时间段按天分割到每天的价格
2.选择：选择每天上比较后录的合同的价格
3.归并：按价格相同与否，将每天的价格归并成时间段
之前是用存储过程做的。（因为这样会减少网络传输），而且不是一个存储过程，因为不同的价格计算条件和方式有一些微小的差别。
很不幸，业务有变化了，这些存储过程都要改动，而且目前有了一些性能方面的问题：
我们的DB是用的oracle 10 的RAC，AP服务器用的是weblogic 8 集群。在计算所有酒店的一天价格时，用存储过程要10多分钟。如果计算多几天的价格，则会因为存储过程时间过长，造成AP报timeout。
为了应对业务的变化（也因为有了这些变化，才敢有以下的做法），也为了解决性能问题，我决定把这些业务逻辑从DB中移出来，放在程序中去。我们用面向对象的方法进行分析和设计，用若干业务领域类以及持久化DAO代替了这些存储过程。用了大约2个人月的时间，完成上线了。 计算一天价格的时间下降到3分钟，仔细检查了一下，业务接口中有个地方可以优化。优化后，计算一天价格的时间下降到不足一分钟了，多天的价格计算也可以进行了！
总结一下这次过程：
1、存储过程处理的过程复杂时，性能未必好！
2、程序中也有很多地方是可以优化的。
3、面向对象的程序应对业务逻辑的变化，有时比存储过程还要好！

评论

61 楼 ironsabre 2008-07-31  

ironsabre 写道

icewubin 写道

pp21 写道

[e-mail] 写道

这种事情可能发生吗？ 除非你的存储过程写的很糟糕！
听上去酒店n大才能发生这种情况。假定酒店有1000个房间，每个房间每天产生100条相关数据，写存储过程每天算，估计最多1分钟。

同意楼上的观点，lz没有对症下药。
存储过程的调优是比较艰辛，需要耐心。
例如，在我现在的这个项目，做数据抽取，以前用java代码做抽取，300组记录(包括主表，子表)，这还其中涉及了许多统计，需要20分钟以上，客户天天投诉。后来将全部java代码改成存储过程，并对每个sql语句都进行调优。最后的效果是300组记录的数据抽取，存储过程只要400多毫秒就完成，如果算上其他的损耗，整个过程也不超过2秒。客户对这个结果非常满意。

要说效率为什么现在没多少人用汇编和机器二进制码去做，这个道理大家都懂，某些人不要因为自己sql怎么怎么好就说楼主这样那样不行，我看楼主说的基本都没什么太大的问题。

1.任何一个项目的资源都是有限的，不可能今天需要存储过程高手，公司里就冒出个存储过程高手来编代码，如果他跳槽了，谁来维护，花很少的钱再去找一个，你去招招看。

2.sql作为一种面向过程的dsl语言，在某些方面不如面向对象的语言，很正常么，尤其是在JVM的帮助下，Java当然可以非常高效，楼主都已经说了他们的业务逻辑的特点了，有些人还在强调什么算法，算法是业务逻辑么？

3.sql和一些特殊的sql语句无非就是对关系数据库的操作和优化操作，但是一旦这些优化的命令和操作对现有的的复杂业务逻辑计算提供不了太多的帮助，计算效率下降，代码量成倍增加，可维护性就会很差，维护人员时间成本（包含工资成本）就非常高。

4.楼主也说了，有些逻辑（其实就是适合用sql来做的）会考虑再次放到存储过程来做，说得很好啊。

5.有一位网友说的也很好，很多时候数据库就是瓶颈，扩展的代价远比扩展应用服务器昂贵和复杂，根本就不应该占用宝贵的数据库资源做业务逻辑操作。

再次说明，存储过程很强大么？怎么不去写操作系统或者是httpserver呢？有多线程么？有分代垃圾回收么？有清晰完整的内存数据存储模型么？
特定的DSL语言就是做特定的事情。

问题是LZ没有找到性能瓶颈在哪里。

我看你也属于这种，找不到真正问题所在的主。
因为这么明显的贴子你都看不到真正的问题在哪里。

60 楼 ironsabre 2008-07-31  

icewubin 写道

pp21 写道

[e-mail] 写道

这种事情可能发生吗？ 除非你的存储过程写的很糟糕！
听上去酒店n大才能发生这种情况。假定酒店有1000个房间，每个房间每天产生100条相关数据，写存储过程每天算，估计最多1分钟。

同意楼上的观点，lz没有对症下药。
存储过程的调优是比较艰辛，需要耐心。
例如，在我现在的这个项目，做数据抽取，以前用java代码做抽取，300组记录(包括主表，子表)，这还其中涉及了许多统计，需要20分钟以上，客户天天投诉。后来将全部java代码改成存储过程，并对每个sql语句都进行调优。最后的效果是300组记录的数据抽取，存储过程只要400多毫秒就完成，如果算上其他的损耗，整个过程也不超过2秒。客户对这个结果非常满意。

要说效率为什么现在没多少人用汇编和机器二进制码去做，这个道理大家都懂，某些人不要因为自己sql怎么怎么好就说楼主这样那样不行，我看楼主说的基本都没什么太大的问题。

1.任何一个项目的资源都是有限的，不可能今天需要存储过程高手，公司里就冒出个存储过程高手来编代码，如果他跳槽了，谁来维护，花很少的钱再去找一个，你去招招看。

2.sql作为一种面向过程的dsl语言，在某些方面不如面向对象的语言，很正常么，尤其是在JVM的帮助下，Java当然可以非常高效，楼主都已经说了他们的业务逻辑的特点了，有些人还在强调什么算法，算法是业务逻辑么？

3.sql和一些特殊的sql语句无非就是对关系数据库的操作和优化操作，但是一旦这些优化的命令和操作对现有的的复杂业务逻辑计算提供不了太多的帮助，计算效率下降，代码量成倍增加，可维护性就会很差，维护人员时间成本（包含工资成本）就非常高。

4.楼主也说了，有些逻辑（其实就是适合用sql来做的）会考虑再次放到存储过程来做，说得很好啊。

5.有一位网友说的也很好，很多时候数据库就是瓶颈，扩展的代价远比扩展应用服务器昂贵和复杂，根本就不应该占用宝贵的数据库资源做业务逻辑操作。

再次说明，存储过程很强大么？怎么不去写操作系统或者是httpserver呢？有多线程么？有分代垃圾回收么？有清晰完整的内存数据存储模型么？
特定的DSL语言就是做特定的事情。

问题是LZ没有找到性能瓶颈在哪里。

59 楼 ironsabre 2008-07-31  

pp21 写道

[e-mail] 写道

这种事情可能发生吗？ 除非你的存储过程写的很糟糕！
听上去酒店n大才能发生这种情况。假定酒店有1000个房间，每个房间每天产生100条相关数据，写存储过程每天算，估计最多1分钟。

同意楼上的观点，lz没有对症下药。
存储过程的调优是比较艰辛，需要耐心。
例如，在我现在的这个项目，做数据抽取，以前用java代码做抽取，300组记录(包括主表，子表)，这还其中涉及了许多统计，需要20分钟以上，客户天天投诉。后来将全部java代码改成存储过程，并对每个sql语句都进行调优。最后的效果是300组记录的数据抽取，存储过程只要400多毫秒就完成，如果算上其他的损耗，整个过程也不超过2秒。客户对这个结果非常满意。

你成了另一个LZ.
只是方向变了。

58 楼 icewubin 2008-07-31  

pp21 写道

[e-mail] 写道

这种事情可能发生吗？ 除非你的存储过程写的很糟糕！
听上去酒店n大才能发生这种情况。假定酒店有1000个房间，每个房间每天产生100条相关数据，写存储过程每天算，估计最多1分钟。

同意楼上的观点，lz没有对症下药。
存储过程的调优是比较艰辛，需要耐心。
例如，在我现在的这个项目，做数据抽取，以前用java代码做抽取，300组记录(包括主表，子表)，这还其中涉及了许多统计，需要20分钟以上，客户天天投诉。后来将全部java代码改成存储过程，并对每个sql语句都进行调优。最后的效果是300组记录的数据抽取，存储过程只要400多毫秒就完成，如果算上其他的损耗，整个过程也不超过2秒。客户对这个结果非常满意。

要说效率为什么现在没多少人用汇编和机器二进制码去做，这个道理大家都懂，某些人不要因为自己sql怎么怎么好就说楼主这样那样不行，我看楼主说的基本都没什么太大的问题。

1.任何一个项目的资源都是有限的，不可能今天需要存储过程高手，公司里就冒出个存储过程高手来编代码，如果他跳槽了，谁来维护，花很少的钱再去找一个，你去招招看。

2.sql作为一种面向过程的dsl语言，在某些方面不如面向对象的语言，很正常么，尤其是在JVM的帮助下，Java当然可以非常高效，楼主都已经说了他们的业务逻辑的特点了，有些人还在强调什么算法，算法是业务逻辑么？

3.sql和一些特殊的sql语句无非就是对关系数据库的操作和优化操作，但是一旦这些优化的命令和操作对现有的的复杂业务逻辑计算提供不了太多的帮助，计算效率下降，代码量成倍增加，可维护性就会很差，维护人员时间成本（包含工资成本）就非常高。

4.楼主也说了，有些逻辑（其实就是适合用sql来做的）会考虑再次放到存储过程来做，说得很好啊。

5.有一位网友说的也很好，很多时候数据库就是瓶颈，扩展的代价远比扩展应用服务器昂贵和复杂，根本就不应该占用宝贵的数据库资源做业务逻辑操作。

再次说明，存储过程很强大么？怎么不去写操作系统或者是httpserver呢？有多线程么？有分代垃圾回收么？有清晰完整的内存数据存储模型么？
特定的DSL语言就是做特定的事情。

57 楼 pp21 2008-07-30  

[e-mail] 写道

这种事情可能发生吗？ 除非你的存储过程写的很糟糕！
听上去酒店n大才能发生这种情况。假定酒店有1000个房间，每个房间每天产生100条相关数据，写存储过程每天算，估计最多1分钟。

同意楼上的观点，lz没有对症下药。
存储过程的调优是比较艰辛，需要耐心。
例如，在我现在的这个项目，做数据抽取，以前用java代码做抽取，300组记录(包括主表，子表)，这还其中涉及了许多统计，需要20分钟以上，客户天天投诉。后来将全部java代码改成存储过程，并对每个sql语句都进行调优。最后的效果是300组记录的数据抽取，存储过程只要400多毫秒就完成，如果算上其他的损耗，整个过程也不超过2秒。客户对这个结果非常满意。

56 楼 hu_huter 2008-07-30  

这种事情可能发生吗？ 除非你的存储过程写的很糟糕！
听上去酒店n大才能发生这种情况。假定酒店有1000个房间，每个房间每天产生100条相关数据，写存储过程每天算，估计最多1分钟。

55 楼 kakaluyi 2008-07-30  

这论坛看来什么人都有 这个帖子某个人看起来极其让人不爽，请自重

54 楼 ladofwind 2008-07-29  

slaser 写道

分析楼主的问题，焦点集中在下面几点。
1.java能做的数据库查询操作是否存储过程都能做？
2.同样算法下一般存储过程是否会比java代码执行效率高？
3.存储过程是否比java代码难于维护？

我的答案是：
1.基本可以。
2.是。
3.是。

基本结论就这样了，楼主就是没经过太多验证就放出一个结论，到此为止吧。呵呵

53 楼 slaser 2008-07-29  

分析楼主的问题，焦点集中在下面几点。
1.java能做的数据库查询操作是否存储过程都能做？
2.同样算法下一般存储过程是否会比java代码执行效率高？
3.存储过程是否比java代码难于维护？

我的答案是：
1.基本可以。
2.是。
3.是。

52 楼 qjzhyf 2008-07-29  

LZ，我支持你啊。虽然经常写sql,但却很少写存储过程，原因是不太懂。现在java里面有支持调用存储过程的Api。不过，也很少去使用。

51 楼 zhuyx808 2008-07-29  

只能说明一个问题，sql很吃力，或者sql很一般，为什么能在java中过滤就不能在sql中过滤，数据库自操作速度应该是很快的了，只能是你们原来的存储过程写的很烂，建议LZ在sql上多下点功夫

50 楼 abo 2008-07-29  

楼主怎么就这么倒霉？不就是说了实话？

49 楼 ironsabre 2008-07-28  

哪里麻烦，哪里性能不好。

为什么你在Java里可以用代码检查，而到了pl/sql里就需要用到临时表？

你举几个明确的修改点出来。

48 楼 hyhongyong 2008-07-28  

ironsabre 写道

    
你讲一下，你在Java中优化的哪些点，是在pl/sql中不能做到的。

（如某些条件的过滤）？？？

不是说不能做，而是麻烦或性能不好。
比如说，有些数据记录是不规范的，代码中就可以把规范检查的动作放在某些类中。而存储过程怎么做呢？把数据记录都放在临时表中，把不规范的数据删除掉。
对于过滤是如此，对于某些业务逻辑也是一样，比如：如果供应商不是酒店，要从另一个价格表中取数据。
具体的点有很多，只是想说明：程序优化的方向和存储过程优化的方向不同！

47 楼 ironsabre 2008-07-28  

hyhongyong 写道

AllenZhang 写道

我感觉，这只能说明你们那个存储过程写的太差

我们没有比较好的DBA，只能说尽量去优化。事实上存储过程最初没有这么慢，但数据库的数据和参数设置都在变化中，性能也是一点点变的不好。
这也是我们把业务逻辑拿出来的一个原因，存储过程这次调优好了，数据变化可能慢慢使性能差了。而程序基本上调优后，变化基本上只好数据量有关，优化的手段也多。
另外使用存储过程，也并不是说程序中就没有业务逻辑了，程序和存储过程的结合过程不好，整体性能也比较差。
之前的程序，存储过程是处理一天的数据，程序是循环调用。

rainchen 写道

存储过程的确有些地方不如在代码层容易优化，如缓存，在业务逻辑的代码层里，可以再插入些缓存层，如Memcached等。
这个帖子的问题主要是楼主提供的理据太含糊，支撑不起他的结论。

事实上我们也考虑过缓存，一方面目前的性能够用了，另一方面客户要求是实时的。

代码层的优化，大都在某个点上（如某些条件的过滤）。而存储过程的优化，通常是在某个面上（如实现归并的算法）。

你讲一下，你在Java中优化的哪些点，是在pl/sql中不能做到的。

（如某些条件的过滤）？？？

46 楼 tonik 2008-07-28  

你那些对象也只是jdbc、sql抽出来的

45 楼 hyhongyong 2008-07-28  

AllenZhang 写道

我感觉，这只能说明你们那个存储过程写的太差

我们没有比较好的DBA，只能说尽量去优化。事实上存储过程最初没有这么慢，但数据库的数据和参数设置都在变化中，性能也是一点点变的不好。
这也是我们把业务逻辑拿出来的一个原因，存储过程这次调优好了，数据变化可能慢慢使性能差了。而程序基本上调优后，变化基本上只好数据量有关，优化的手段也多。
另外使用存储过程，也并不是说程序中就没有业务逻辑了，程序和存储过程的结合过程不好，整体性能也比较差。
之前的程序，存储过程是处理一天的数据，程序是循环调用。

rainchen 写道

存储过程的确有些地方不如在代码层容易优化，如缓存，在业务逻辑的代码层里，可以再插入些缓存层，如Memcached等。
这个帖子的问题主要是楼主提供的理据太含糊，支撑不起他的结论。

事实上我们也考虑过缓存，一方面目前的性能够用了，另一方面客户要求是实时的。

代码层的优化，大都在某个点上（如某些条件的过滤）。而存储过程的优化，通常是在某个面上（如实现归并的算法）。

44 楼 fudehai001 2008-07-28  

应该不是存储过程问题，
ORACLE ERP 业务够复杂吧，
但业务逻辑基本上都是用存储过程实现的，
个人感觉应该是设计或代码写得不完美。
个人平时使用存储过程感觉还行。
仅供参考。

43 楼 AllenZhang 2008-07-28  

我感觉，这只能说明你们那个存储过程写的太差

42 楼 slaser 2008-07-27  

<div class='quote_title'>hyhongyong 写道</div>
<div class='quote_div'>
<p>1、存储过程处理的过程复杂时，性能未必好！ <br/>2、程序中也有很多地方是可以优化的。 <br/>3、面向对象的程序应对业务逻辑的变化，有时比存储过程还要好！</p>
</div>
<p>1.要看你对存储过程的驾驭能力，如果一般，确实未必好。</p>
<p>2.确实是废话。</p>
<p>2.不是“有时”，是大多数情况。如果你是程序员，不是DBA,基本会希望在代码里看业务逻辑。</p>
<p> </p>
<p>我想存储过程的问题，大部分人是有定论的，就是“除非性能需要，业务逻辑不放存储过程中”。</p>
<p>例外的情况也是有的，我现在手上的一个项目业务逻辑基本就是存储过程，包括很简单的添加，删除，修改。没办法，当时做这个项目的人，在写程序技能上很差。</p>
<p> </p>
<p>楼主勾出了性能优化问题，却不拿出足够细节，让此帖失色。</p>