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

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

评论

101 楼 johnnywww 2008-08-20  

我认为存储过程和代码实现都是业务逻辑实现方式，在代码里实现可以让业务逻辑处理较好的和DB分离。用存储过程可以在性能上有较好的应用。

100 楼 icewubin 2008-08-20  

cdjjh 写道

我的思路与楼主相反，经常把复杂的逻辑运算放到oracle的存储过程去做，经过几年的实践，感觉效果挺不错的，这种思路得到全公司开发人员的认可，顺便说一下我们的数据库规模，核心表从几十万至千万条记录，整个数据库有几十个G。

我随便瞎举举例子，和搂主的情况无关，比如要对一列数据作处理，放入另一个表中存储结果。

假设处理的需求是，对一个数据做数字签名，顺便再来个zip压缩，呵呵。

即使存储过程有这方面的计算函数，消耗数据库的CPU可不是一点点啊。
很多人好像还没有多台计算机的概念，应该假想一下，每台机器都在做什么计算操作，不要搞得好像DB机器的单台机器可以无限扩展，不要以为数据库集群的扩展获得的性能回报曲线是线形的，不要以为数据库的集群是很容易（各种成本都很高）。

例子是有点极端，还是强调应用需求和场景。

99 楼 cdjjh 2008-08-20  

我的思路与楼主相反，经常把复杂的逻辑运算放到oracle的存储过程去做，经过几年的实践，感觉效果挺不错的，这种思路得到全公司开发人员的认可，顺便说一下我们的数据库规模，核心表从几十万至千万条记录，整个数据库有几十个G。

98 楼 zh_zhai 2008-08-18  

存储过程及数据结构设计的有问题嘛。这么少的业务逻辑要跑10分钟，数据量才百万级。赶快找DBA做优化吧。

97 楼 kusoft 2008-08-17  

还好我没有这样做,我本想把一些简单的业务放到存储过程中去做.根据上面总结.降低了开发效率.维护效率低.所以还是打算放到java做业务处理.

96 楼 zjh666qq 2008-08-16  

存储过程的效率不可能这么差，应该是写法有问题，我们上千万的数据量算法逻辑绝对比你所说的复杂，查询速度也就是1-2分钟
个人建议：
    1。可充分利用oracle 的分析函数
    2。适当的通过一些临时表做缓冲
    3。处理的数据流做下分析，考虑是否可以通过适当的配置界面来减少后台的频繁操作

95 楼 ebeach 2008-08-16  

ajoo 写道

写存储过程比较常见的错误是：

loop over a cursor
    select foo from table where x=loopVar

这种东西不慢就出鬼了。一般这种东西，把select写得好点，从几十分钟降到十几秒也是正常的。

顶
很多都是游标（甚至可能是嵌套游标）代替了查询，导致的效率低下。

其实楼主应该在统计SQL上下些功夫，减少了循序效率肯定可以高几个级别。

94 楼 ajoo 2008-08-15  

写存储过程比较常见的错误是：

loop over a cursor
    select foo from table where x=loopVar

这种东西不慢就出鬼了。一般这种东西，把select写得好点，从几十分钟降到十几秒也是正常的。

93 楼 VincentChen 2008-08-15  

存储过程很好啊，有变动改一下编译一下马上就生效了。哈哈。效率绝对好，你的10分钟绝对是写程序的太烂了

92 楼 hsq972 2008-08-15  

jjx 写道

icewubin 写道

jjx 写道

其实一些人轻视存储过程,只不过是在掩盖自己对sql 方面的无知

sql 中的学问大着呢,很多都涉及到 算法问题

说话不要随便上纲上线，你对数据结构和算法了解多少呢？存储过程中的算法占整个计算机算法的领域能有多少呢？

你又是怎么知道别人是轻视呢？别人要掩盖呢？我还能说你只不过是在掩盖自己对JVM的无知，对数据结构的无知等等。这种话说了有意义么？你怎么不说大家都轻视操作系统和编译原理呢？

每一种语言，每一种算法，每一种策略都有自己的领域和应用场景，而且随着研究的深入，各自都能有不同的发展，没什么一种语言能包办所有的事情的。

每一个技术人员，精力也是有限的，有的选择了Unix C，有的选择了Java，有的选择了Linux内核，有的选择了.net，有的选择了ROR等等，因素有很多，难道这个世界上只有存储过程么？

了解的比你少,总行了吧,火气干嘛这么大

我只是指某些人,这些人大多只懂得select,delete ,update而已. 这是事实,再说做系统内核或是搞驱动,做单片机的的会在这里讨论sql吗?做企业数据库应用,那个又能回避sql呢.,我做程序已经超过10年,唯一可以自夸的是见过的人比你多 或许你见过的人比我更多也说不定,那么就算了,你正确. 呵呵,不用搞的这么不开心

是呀!现在软件开发细分得越来越明显了.不再象以前一本经书读到老.

91 楼 kunee 2008-08-15  

不知道楼主是不是想描述这样的问题。

单记录计算量复杂，取的数据相对简单。

写在JAVA里集群计算效率提高是很明显，多应用同时做。

偶在电信行业，即使存储过程也是会做成各区块分开计算，同时跑。

我们的数量至少是500W以上

90 楼 xixix2004 2008-08-12  

athene11 写道

从LZ的描述看，应该是存储过程中select语句或者其它语句的关联有性能问题。

我赞同这个观点。是存储过程的语句有问题。

89 楼 jjx 2008-08-04  

icewubin 写道

jjx 写道

其实一些人轻视存储过程,只不过是在掩盖自己对sql 方面的无知

sql 中的学问大着呢,很多都涉及到 算法问题

说话不要随便上纲上线，你对数据结构和算法了解多少呢？存储过程中的算法占整个计算机算法的领域能有多少呢？

你又是怎么知道别人是轻视呢？别人要掩盖呢？我还能说你只不过是在掩盖自己对JVM的无知，对数据结构的无知等等。这种话说了有意义么？你怎么不说大家都轻视操作系统和编译原理呢？

每一种语言，每一种算法，每一种策略都有自己的领域和应用场景，而且随着研究的深入，各自都能有不同的发展，没什么一种语言能包办所有的事情的。

每一个技术人员，精力也是有限的，有的选择了Unix C，有的选择了Java，有的选择了Linux内核，有的选择了.net，有的选择了ROR等等，因素有很多，难道这个世界上只有存储过程么？

了解的比你少,总行了吧,火气干嘛这么大

我只是指某些人,这些人大多只懂得select,delete ,update而已. 这是事实,再说做系统内核或是搞驱动,做单片机的的会在这里讨论sql吗?做企业数据库应用,那个又能回避sql呢.,我做程序已经超过10年,唯一可以自夸的是见过的人比你多 或许你见过的人比我更多也说不定,那么就算了,你正确. 呵呵,不用搞的这么不开心

88 楼 ironsabre 2008-08-04  

To:icewubin

我想表达的是，楼主的这个性能问题根本不是由于存储过程或Java造成的。

你告诉我，你想表达什么？

你老是假想别人在夸PL/SQL，然后自己架起一个耙子在那打得很开心。很好玩。

87 楼 icewubin 2008-08-04  

jjx 写道

其实一些人轻视存储过程,只不过是在掩盖自己对sql 方面的无知

sql 中的学问大着呢,很多都涉及到 算法问题

说话不要随便上纲上线，你对数据结构和算法了解多少呢？存储过程中的算法占整个计算机算法的领域能有多少呢？

你又是怎么知道别人是轻视呢？别人要掩盖呢？我还能说你只不过是在掩盖自己对JVM的无知，对数据结构的无知等等。这种话说了有意义么？你怎么不说大家都轻视操作系统和编译原理呢？

每一种语言，每一种算法，每一种策略都有自己的领域和应用场景，而且随着研究的深入，各自都能有不同的发展，没什么一种语言能包办所有的事情的。

每一个技术人员，精力也是有限的，有的选择了Unix C，有的选择了Java，有的选择了Linux内核，有的选择了.net，有的选择了ROR等等，因素有很多，难道这个世界上只有存储过程么？

86 楼 jjx 2008-08-04  

其实一些人轻视存储过程,只不过是在掩盖自己对sql 方面的无知

sql 中的学问大着呢,很多都涉及到 算法问题

85 楼 stme 2008-08-04  

对，现在所做的很大一部分系统的核心业务都是在存储过程中实现的。
现实系统中，一般都是：
存储过程做业务；
报表展现数据；
java用于数据的录入和输出。

84 楼 icewubin 2008-08-04  

ray_linn 写道

你上面举的任何一个例子，都没办法证明他们在java系统重就没有用存储过程，尤其是平安银行的例子，启用ibatis的原因，完全可能是因为业务逻辑全部在存储过程中，而用java做个接口而已。

上面以前有很多有核心业务经验的人（包括我自己）说明，存储过程还是开发核心业务的最重要的工具。

您说得很对很可观，尤其是最后一句话，完全认同。

但是前面几个人在没有完全了解楼主的情况下，妄下判断，要不是出现一些反对声音，他们会把存储过程捧上天呢。
我只是想说存储过程不适合解决所有类型的业务逻辑，但是也完全承认存储过程的重要作用。

平安银行和交通银行的非核心系统有相当一部分的业务逻辑是基本不用存储过程的，交通银行的核心系统肯定用的，历史原因，至于平安银行核心系统存储过程使用的比例（占所有业务逻辑的比重）目前不得而知。

我还是那句话，当年的金融系统用存储过程是完全正确的，就像电信一度是用corba一样，但是时间在往前走，虽然以存储过程的解决方案本身也在不断反展（主要是外部的方案），但是选择是越来越多了。

83 楼 ray_linn 2008-08-04  

你上面举的任何一个例子，都没办法证明他们在java系统重就没有用存储过程，尤其是平安银行的例子，启用ibatis的原因，完全可能是因为业务逻辑全部在存储过程中，而用java做个接口而已。

上面以前有很多有核心业务经验的人（包括我自己）说明，存储过程还是开发核心业务的最重要的工具。

82 楼 icewubin 2008-08-03  

ray_linn 写道

icewubin 写道

几个新起的国外银行在中国的核心系统有不少都是Java的，国内也有用IBM的CICS作交易中间件的，也是java的。

谁在这里大放厥词,我参加过农总行的业务编写,用的是CICS和存储过程. CICS谁告诉你是java的,我们用的C+ESQL.

我知道CICS历史悠久，他不会出新版么？


http://publib.boulder.ibm.com/infocenter/txformp/v6r0m0/index.jsp?topic=/com.ibm.cics.te.doc/erziak0025.htm

http://www2.ccw.com.cn/1998/49/173193.shtml

进一步：CICS这个例子我不是非常的确定，不过我和你可能都没说到点子上，我们说的都是调用的语言支持而已。

从下面的介绍来看他们使用MQ，再加上多数据库的支持，感觉是Java的可能性还是有点的。
http://publib.boulder.ibm.com/infocenter/txformp/v6r0m0/topic/com.ibm.cics.te.doc/nl/zh/erziaz0007.htm#dc004f1

不过另一个例子“建行的证券交易系统”，那个是全部跑在BEA的weblogic上的，那个是可以确定的。

还有平安银行新起的不少项目（他们没有旧项目）也能确定是用Java的，但是不确定他们的Java架构是否用在了他们的核心系统。只确定他们有自己的框架，结构是Spring（自己改良的）+Struts+ibatis，连EJB的事务都不用。

还有我们公司另一个项目组做的交行的客户评级系统本来是用EOS（大家别笑）做的，后来交行的傻瓜们说改用Java做其它应用，觉得EOS太烂。不过那个肯定不是核心系统。