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

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

评论

41 楼 slaser 2008-07-27  

right now 写道

rock_li 写道

楼主发这个贴证明了他的勇气，至少他用自己的方式证明了把设计不好的存储过程用面向对象的观点达到了自己的效果。
技术是可以学习和锻炼的，勇气和创新才是根本。 况且存储过程的高手不一定能优化系统达到楼主想要的结果。当然如果高手能在这个例子分析存储过程和面向对象的不同优化思路让我们学习一下是最好的。不然大家都去做DBA好了：）

很少看到这种敢于表达另类思想（去证明业务逻辑放到程序比DB块的文章），而且愿意与大家共享的好人。请接受一个不是高手的程序员的谢谢。

勇气？逗死我了，不是有入门讨论区吗？
你是马甲吗？
没看出来你怎么把不好的存储过程用面向对象的观点达到了自己的效果，show代码看看？
另类思想？思想在什么地方，另类在哪里？
自己都说不清楚的东西不会到问答频道提问啊？浪费大家的时间

你除了骂还有什么？要骂你去天涯。楼主推理过程确实有些问题，但是毕竟是其开发的真实体验，楼主这种交流态度我是很欣赏的，至于问题，应该不断的去引导出来？我没看出他在浪费大家时间，我倒觉得你在发泄自己的不满，和浪费大家时间。

40 楼 rainchen 2008-07-27  

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

39 楼 srdrm 2008-07-26  

也许你没并没有真正尝试去调优存储过程吧

38 楼 spiritfrog 2008-07-26  

确实没有看出来lz怎么用java程序来优化性能的， 从而比存储过程要快。
至于提出的第一点和第二点有些模糊，没有给出具体情况；而第三点是显而易见的，又不知道lz是怎么干的。

37 楼 coolmenu 2008-07-26  

数据库的 trigger是影响性能的.少用trigger

36 楼 skzr.org 2008-07-26  

CDMA1333 写道

我还是很欣赏存储过程的，我原先生成1批500000条的12位随机数，要求不与表中已有的数据相重复，以前用java代码写，简直实现不了，现在改用存储过程了，只要10分钟了

才50W的数据量，Java做怎么会这么慢呢！估计是没有设计好吧！

对于存储过程实现业务过程，我一直不赞成的！
1 浪费数据库资源
2 复杂的流程处理
3 维护问题
4 移植问题（不同数据库可能需要重写）
5 关键一点无法扩展

如果使用服务来实现（向对于Java）
1 充分利用廉价的计算资源
2 灵活的面向对象处理业务
3 维护简单
4 基本上没有问题
5 很强的扩展性

现在我们公司的新系统什么都依赖于数据库的sql来做，为了做业务加了不少的触发器，真的很担忧性能问题！（现在老实说性能问题已经出现了）

对比以前的系统现在感觉业务处理使用程序来做的优势就出现了！

35 楼 0701 2008-07-26  

rock_li 写道

楼主发这个贴证明了他的勇气，至少他用自己的方式证明了把设计不好的存储过程用面向对象的观点达到了自己的效果。
技术是可以学习和锻炼的，勇气和创新才是根本。 况且存储过程的高手不一定能优化系统达到楼主想要的结果。当然如果高手能在这个例子分析存储过程和面向对象的不同优化思路让我们学习一下是最好的。不然大家都去做DBA好了：）

很少看到这种敢于表达另类思想（去证明业务逻辑放到程序比DB块的文章），而且愿意与大家共享的好人。请接受一个不是高手的程序员的谢谢。

勇气？逗死我了，不是有入门讨论区吗？
你是马甲吗？
没看出来你怎么把不好的存储过程用面向对象的观点达到了自己的效果，show代码看看？
另类思想？思想在什么地方，另类在哪里？
自己都说不清楚的东西不会到问答频道提问啊？浪费大家的时间

34 楼 rock_li 2008-07-26  

楼主发这个贴证明了他的勇气，至少他用自己的方式证明了把设计不好的存储过程用面向对象的观点达到了自己的效果。
技术是可以学习和锻炼的，勇气和创新才是根本。 况且存储过程的高手不一定能优化系统达到楼主想要的结果。当然如果高手能在这个例子分析存储过程和面向对象的不同优化思路让我们学习一下是最好的。不然大家都去做DBA好了：）

很少看到这种敢于表达另类思想（去证明业务逻辑放到程序比DB块的文章），而且愿意与大家共享的好人。请接受一个不是高手的程序员的谢谢。

33 楼 CDMA1333 2008-07-26  

我还是很欣赏存储过程的，我原先生成1批500000条的12位随机数，要求不与表中已有的数据相重复，以前用java代码写，简直实现不了，现在改用存储过程了，只要10分钟了

32 楼 movingboy 2008-07-25  

hyhongyong 写道

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

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

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

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

大家对你的优化有不理解的地方很正常嘛！不必因为这个就泄气了。

我还是没能理解为什么“因为存储过程的技术限制，选择和归并是需要花些时间的。而程序可以优化这些过程”，为什么会选择或导致使用“DB表锁机制”？此外你说“真正用过oracle做过存储过程的应该都清楚，记录的选择（从若干条件相同的记录中选择某些特殊的记录，比如价格最低的，某字段最大的）和归并都会占用不小的时间。”，我并不认为这是一个通用的结论。

不过，如果你们的团队中缺少不错的DB开发人员，在Java层面上进行优化也是不错的选择吧！

31 楼 zhajie 2008-07-25  

不支持使用存储过程！！！

一、存储过程不易移植（相对于java）

二、存储过程不易修改（相对于java）

三、存储过程的性能比不上java（不是特别大数据量的情况下），主要是存储过程语言不够灵活，不能灵活的使用缓存。

四、DB越简单越好，表设计时的字段只要两种类型（number,varchar）,建立索引。只有简单的数据库才能获得整体的高性能。

30 楼 coolmenu 2008-07-25  

DB表锁机制，存储过程占用表锁的时间相对长


楼主的存储过程要锁表嘛? 占用表锁的时间相对长是什么意思?

29 楼 hyhongyong 2008-07-25  

sam0411 写道

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

很好,很强大!

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

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

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

28 楼 hyhongyong 2008-07-25  

movingboy 写道

ironsabre 写道

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

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

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

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

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

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

27 楼 lonelystarchen 2008-07-25  

恩,有道理!

ironsabre 写道

movingboy 写道

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

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

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

26 楼 sam0411 2008-07-25  

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

很好,很强大!

25 楼 movingboy 2008-07-25  

ironsabre 写道

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

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

24 楼 ironsabre 2008-07-25  

movingboy 写道

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

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

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

23 楼 0701 2008-07-25  

movingboy 写道

right now 写道

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

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

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

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

22 楼 movingboy 2008-07-25  

right now 写道

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

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