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

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

楼主能否再深入一点说说是如何优化的？

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

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

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

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

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

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

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

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

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