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

呵呵，lz的无厘头风格类似我碰到的某位CTO。

和这个小公司合作做一个项目，我提供外包服务， 也就是全程咨询顾问兼核心开发服务。合同接受以后他们做压力测试提出有性能问题，给出的一些数据是这样的
1. 在我要求下进行跟踪， 全部sql执行时间都在1ms以内。数据库中也不存在锁状态。
2. 在大压力的情况下， 10%左右的操作执行时间会超过60秒。而此时不管是数据库还是应用服务器，资源消耗都很低。

这个操作大约会涉及到10来次数据库操作，正常情况下应该在10ms以内结束。正常人看到这就应该去想，应该存在资源锁，对吧。
我给出的建议是
1. 做profiling，判断资源锁情况
2. 在拿到1的数据下，决定是否可以通过调整系统参数或者使用缓存解决问题。

但是这位老大一口咬定是sql调用过多，用存储过程肯定可以解决这个问题，一拍脑袋就化了几个星期时间改成存储过程了，然后很得意的告诉我，问题已经解决了。看起来好像很正确，但是就这种想当然的做法，然后是改了一个问题，又出现新的问题，导致他们所谓的调优居然化了6个月。

其实对于这种小case， java调用和sql调用的真正差别可能也就是10ms 和8ms的差别而已，既然90%的操作执行都正常，显然不是sql调用过多的问题， 拍拍脑袋都知道了mysql没sp支持的时候，一个操作做10来次sql 操作算的什么。 并发情况下出问题肯定是锁的缘故。我安排人私下测试，发现更换了一个jdk以后问题就解决了。

后来私下问了他们下面的一些开发人员，发现这6个月大部分时间都是听老大瞎折腾。 比如他们老大不理解proxy这种模式，误以为我自己开发了一套jdbc驱动，然后就本着怀疑一切的原则组织测试了一个星期，然后得出一个结论，使用我编写的jdbc，速度比原生的慢10倍，让我哭笑不得，而且这还是开发人员再三和他解释proxy只是做了一次转码操作的情况下。


好在这个项目后来也基本没人用，否则都不知道丫怎么死的。

谁在这里大放厥词,我参加过农总行的业务编写,用的是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太烂。不过那个肯定不是核心系统。

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

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

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

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

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

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

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

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

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

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

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

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

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

To:icewubin

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

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

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

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

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