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

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

评论

21 楼 rtdb 2008-07-25  

〉优化后，计算一天价格的时间下降到不足一分钟了，多天的价格计算也可以进行了！

呵呵，还要将近一分钟啊。
我以为，这种每天的价格计算应该只算一次就够了，
结果入库即可。

客户查询时可直接获得价格，不需要再算了。

20 楼 0701 2008-07-25  

movingboy 写道

楼上的其中几位，说话请留点余地吧。

楼主愿意把他的体验说出来给大家分享，这是好事啊。或许他是不太清楚为什么，或许他的优化是有问题的，大家可以在技术上进行分析，帮助他把问题搞清楚嘛。如果只是用带打击、否定、不屑一顾的语气说话，楼主还会愿意与大家分享吗？各位又从讨论中收获了什么呢？

好吧，那你说说从中学到什么了？
这是在做性能优化吗？
他反正是自己都搞不清楚，要不你给他解释解释吧

19 楼 steven_652 2008-07-25  

应该是你存储过程写的有问题。

另外你用的是Oracle，不会存在存储过程锁表的问题。

18 楼 movingboy 2008-07-25  

楼上的其中几位，说话请留点余地吧。

楼主愿意把他的体验说出来给大家分享，这是好事啊。或许他是不太清楚为什么，或许他的优化是有问题的，大家可以在技术上进行分析，帮助他把问题搞清楚嘛。如果楼主感受到的只是打击和否定，他还会愿意与大家分享吗？各位又从讨论中收获了什么呢？

17 楼 ironsabre 2008-07-25  

我们的DB是用的oracle 10 的RAC，AP服务器用的是weblogic 8 集群。在计算所有酒店的一天价格时，用存储过程要10多分钟。如果计算多几天的价格，则会因为存储过程时间过长，造成AP报timeout。
-----------------------------------------------------------------------------
另一个问题：这儿应该用异步处理。

16 楼 0701 2008-07-25  

<div class='quote_title'>hyhongyong 写道</div>
<div class='quote_div'>关于存储过程，我们没有专门的DBA进行优化，我只能从自己理解的角度去思考一下： <br/>1、数据量：价格计算过程涉及到从4、5个表中取数据，其中有两个表的数据量较大（几百W）<br/>2、因为存储过程的技术限制，选择和归并是需要花些时间的。而程序可以优化这些过程<br/>3、DB表锁机制，存储过程占用表锁的时间相对长<br/>4、将时间长的存储过程时间，化了简单的DB表查询，压力转移到AP端（事实上压力对DB和AP优化前后都没有什么问题）<br/></div>
<p><br/>你自己DB优化的不好，就说存储过程不好？</p>
<p> </p>
<p>1、存储过程处理的过程复杂时，性能未必好！ <br/>2、程序中也有很多地方是可以优化的。 <br/>3、面向对象的程序应对业务逻辑的变化，有时比存储过程还要好！ </p>
<p> </p>
<p>这三点中的1、3是歪理，2是废话！</p>

15 楼 ironsabre 2008-07-25  

<div class='quote_title'>hyhongyong 写道</div>
<div class='quote_div'>把存储过程用java重写，并不是简单的重写。
原来存储过程的步骤，如果用java直接按那个思路写，效率可能会相当差。
只是用面向对象的方式重新实现一些存储过程的逻辑而已，至于性能的优化，在优化前我们并没有太大的把握，只是觉得性能出现问题了，DB上暂时又没有什么好办法可以提升（实际上我们也试了一些方法，比如存储过程中调试，加索引等但都没有实质提升），用java实现应该是一条路。</div>
<p> </p>
<p>你这不是优化，你是在玩。</p>
<p> </p>
<p>你在开始重写之前都不知道真正的问题出现在哪里。</p>
<p>我想你不也不知道为什么重写之后速度快了。</p>

14 楼 clican 2008-07-25  

酒店一天的数据怎么会有几百万？

13 楼 yjb1981 2008-07-25  

上百万级别的数据，用存储过程肯定比用jdbc实现速度要来的快，那怕是select语句，楼主遇到这种情况，只能说明存储过程写的有问题．

12 楼 athene11 2008-07-25  

都是操作表而已，java和存储过程区别并不大。
从LZ的描述看，应该是存储过程中select语句或者其它语句的关联有性能问题。
把几百万的表进行关联，确实是没有单独的几条select sql快的。
还有LZ说的原存储过程有逻辑不够好导致性能问题。
不过我相信你现在的方式用存储过程一样可以实现。并不是存储过程的问题。

11 楼 ladofwind 2008-07-25  

拿出些优化的事实步骤吧

10 楼 myy 2008-07-25  

我看这只能说明一个问题： 你们原来写的存储过程太太太差了

9 楼 armorking 2008-07-25  

hyhongyong 写道

把存储过程用java重写，并不是简单的重写。原来存储过程的步骤，如果用java直接按那个思路写，效率可能会相当差。只是用面向对象的方式重新实现一些存储过程的逻辑而已，至于性能的优化，在优化前我们并没有太大的把握，只是觉得性能出现问题了，DB上暂时又没有什么好办法可以提升（实际上我们也试了一些方法，比如存储过程中调试，加索引等但都没有实质提升），用java实现应该是一条路。

8 楼 jjx 2008-07-25  

得确,只有在每行有复杂的非数据库类计算时,java代码才有可能会比存储过程高效

另外,你这个优化的前提必须是这个存储过程没有设计问题,否则,这个比较也没有用

7 楼 0701 2008-07-25  

hyhongyong 写道

LS的，说话文明点！
不是我不想好好说，是提交的时候把回车给吃掉了！

得了吧你，别装了！
那你说为什么计算所有酒店的一天价格时，使用存储过程要10多分钟，而优化后只要不足一分钟？为什么原来会有这样的瓶颈？为什么优化后瓶颈消除了？

6 楼 hyhongyong 2008-07-25  

LS的，说话文明点！
不是我不想好好说，是提交的时候把回车给吃掉了！

5 楼 0701 2008-07-25  

乱78糟的，看着我头疼!
有话不能好好说啊,ok?

4 楼 hyhongyong 2008-07-25  

把存储过程用java重写，并不是简单的重写。
原来存储过程的步骤，如果用java直接按那个思路写，效率可能会相当差。
只是用面向对象的方式重新实现一些存储过程的逻辑而已，至于性能的优化，在优化前我们并没有太大的把握，只是觉得性能出现问题了，DB上暂时又没有什么好办法可以提升（实际上我们也试了一些方法，比如存储过程中调试，加索引等但都没有实质提升），用java实现应该是一条路。

3 楼 hyhongyong 2008-07-25  

关于存储过程，我们没有专门的DBA进行优化，我只能从自己理解的角度去思考一下： <br>
1、数据量：价格计算过程涉及到从4、5个表中取数据，其中有两个表的数据量较大（几百W）<br>
2、因为存储过程的技术限制，选择和归并是需要花些时间的。而程序可以优化这些过程<br>
3、DB表锁机制，存储过程占用表锁的时间相对长<br>
4、将时间长的存储过程时间，化了简单的DB表查询，压力转移到AP端（事实上压力对DB和AP优化前后都没有什么问题）<br>

2 楼 duooluu 2008-07-25  

没看出楼主采用了什么优化手段，只是把存储过程用Java重写了一遍效率就上来了？好像关键部分被掐了