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

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

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

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

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

我是觉得最好能鼓励楼主去找到问题，别让他感受太大的挫折而失去了继续研究的积极性以及跟大家交流的热情

http://hyhongyong.iteye.com/blog/forum?only_topic=true
你去看看他有几篇文章是有价值的。

这篇文章你说大家能学到什么？
复杂的逻辑不要用存储过程？为什么？因为不会用！
存储过程的性能未必好？为什么？因为不会用！
程序中也有很多地方是可以优化的，他不说就没人知道？

问题就是在于，我认为，如果自己都不知道问题在哪里，就乱改。
蒙到一个看起来还不错的结果（也不知道为什么会提高），
然后过来写一个总结，这是一件很不好的事情！

嗯，我比较赞同你的分析以及讨论的方式，我也是对他的分析有些怀疑，也希望他能再深入地分析一下。不知楼主看到这个会否有点收获？

看了楼主的贴子, 只有一个感觉: 你们的客户实在是太好说话了. 你连为什么出问题都不知道就让你花出去2个人月的时间?! 更不可思议的是你花了2个人月的时间依然没有发现为什么出问题,客户竟然没有投诉.

很好,很强大!

恩,有道理!

好吧，如果大家认为没有什么帮助，请版主删除就是了！
对不起了，耽误大家的时间了！

说明一下，我们本身不是没对数据库调过优，但因为一是没有数据库的DBA方面的专家，只能自己在存储过程中记时的方式来发现问题并改进，但效果一直不理想！
取价格的逻辑是比较复杂的（具体细节我也没说，也没有什么意思吧！）
我不是没给出自己的分析：

2、因为存储过程的技术限制，选择和归并是需要花些时间的。而程序可以优化这些过程
3、DB表锁机制，存储过程占用表锁的时间相对长
真正用过oracle做过存储过程的应该都清楚，记录的选择（从若干条件相同的记录中选择某些特殊的记录，比如价格最低的，某字段最大的）和归并都会占用不小的时间。而程序在这里是可以优化的！
而且数据是多样性的，存储过程的处理过程要考虑所有可能的数据情况，效率自然会低。而程序在特殊数据的处理上把这些分散在不同对象上。

至于DB锁的问题，可能是我没说清楚，不只是查询价格，也有要把价格查出来并更新到一个实体表中的存储过程！

有个前提：现在业务要改变了，存储过程要改要花时间，同时也有部分程序也要改的。
而且性能现在已经比较差了，不优化行吗？而且我们有对存储过程调过优，只是没有得到好的结果。
此时怎么办？对我们来说，存储过程调优短时间是没有进展的。
程序的优化方法和存储过程是不一样的，存储过程难以优化的地方，程序有方法进行优化！

客户只看结果，能用就OK，不能用你说再明白有什么用？

话说回来，没准我将来会把一部分业务逻辑再放到存储过程中去！