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

问题是你给搂主一个好的方案如何利用他手头的现有资源迅速找到耗时点。

你讨论的时候，大脑里不肯退让的地方就是凡事Java能实现的算法，存储过程一定能原样照搬。

如果楼主采用的Java的实现方法，用存储过程很难实现或者实现成本非常高的话，这就是事实。

如果业务复杂到类似于搜索引擎，或者是移动的T级别的数据处理，都是需要数学模型理论（往往是集群）在后面支撑的，存储过程搞个鬼啊。反复强调了适用领域和范围，脑子还是一根经，一定要强调所有情况下都是存储过程强么？

谁说要在你手下干活，脑子想法这么偏激，只会打击新人抬高自己，论证又举不出实例。

你说谁问题没有搞清楚，我怎么反而觉得你到现在都不明白楼主遇到的问题，不仅仅是技术上的，还有时间和人员上的，巧合，这是巧合么？楼主有一定的Java算法功底是巧合，你怎么不提出一个解决楼主说的分类归并的例子呢？

请直接回答楼主面临的问题，你这样绕弯弯说了半天的空话有啥用啊，你除了嚷嚷存储过程永远胜过Java，还说过什么具体的实质性的建议和方法和举例么？举点实际的例子出来。

你总绕弯弯说明你肚中空空。

同志们，别吵了，结贴吧！

我的本意就是想说明：对于有些问题，存储过程的实现方式与程序的实现方式有不同。只是表达能力有限，没说清楚。

另外我的sql水平，不象有些人想象的如此不济（但也不是DBA级别的），要知道100多个存储过程的移值（从Sybase to oracle）都是我做的。

我的java水平是不错，面向对象的思想较好，也是修改的一个动因。
更关键的是，以后的维护工作等，要交给另一个人，他JAVA还行，但sql还是不如我。

至于项目经理不想用我这样的，我一点都不介意。项目经理总是会考虑风险问题的。不同的项目经理有不同的做法。但是对于我们这个项目来说，目前的解决方案还是客户和项目经理都乐于接受的。

另外我也是项目经理了，如果我以下的程序员有类似的做法，我会考虑实际的情况，给他相应的建议。

最后，希望同志们都别跟了，就此结贴吧！

有过移动的BOSS核心都是存储过程的，扩展性和性能都很不错！
而且可定制性也很强！
存储过程也应该写得类似interface一样，保证入口参数，返回结果！
内部实现隐藏！
可以将存储过程和java代码视为等同的Code;当然涉及高密度的数值，字符串运算的java可能写起来更优，但不排除db也可以高效做到。

如果你认为我想说明　“存储过程永远胜过Java”　的话，那我只能笑笑了。

我想表达的意思刚刚相反，不管用存储过程还是用Java或其他任何语言，对于LZ说的这种简单应用，都不可能因为语言级别的差异产生如何大的耗时差。


结贴吧。

1.你凭什么说楼主应用简单，拿出证据。

2.你说你想表达这个意思，但是“你之前绕弯弯绕了半天可是一直都没提到“这个应用简单”啊。

3.你现在说你表达的不是那个令人误解的意思，为什么到现在才提出来呢？我之前很前面就提出存储过程是不能模拟所有的业务逻辑，你怎么不直接说出你不是这个意思呢？

能不能把你说的扩展性稍微具体化一点啊。
你说的interface是OO里的interface，完全不一样的概念吧，有多态么？不就是一个只能值传递的函数么？那不就是面向过程么？一个面向过程的code如何和跑在JVM虚拟机上的等同，多线程如何实现？如何充分利用主机的多个CPU？

我之前提到的移动T级数据处理不是BOSS系统，是另一个项目。

但凡是有年头的核心系统因为年代关系，基本都是存储过程，这个没什么疑问的。

而且这些老系统因为性能问题，无法水平扩展，只能拼命升级数据库的主机，我在想如果哪天数据量达到类似于上交所的水平，大型机都撑不住了，是不是也学别人全内存操作啊。这样的架构其实是不怎么样的。只不过是历史原因，一直沿用以前的思路和实现思路，也没有任何一个领导敢于换核心架构，所以才会有现在的格局，新起的金融领域项目不一定都是把业务逻辑放在存储过程里的。

个人也有点通讯行业BOSS系统的经验，的确，核心都是存储过程的。对于比较复杂的业务，往往都是采用存储过程数据库封装搞定。（一些存储过程非常复杂，带有数百个参数）。个人感觉这样一个优点上面没提到，就是把不同角色的人员分离开来。
曾经有过公司的系统在实际应用过程中部署后开始很正常，一段时间（数年）后，数据增长到数百万接近千万条记录的规模，一些操作的耗时无法忍受，这时候就是DBA出马的时候，公司有资深DBA,有专门的数据库调优人员，专门负责解决客户数据库遇到的麻烦，这些人往往不是开发，有时候和开发团队没有一点点关系，他们的职责就是数据库的维护，问题解决及优化。这时候，他们不需要看开发的源代码（他们也往往不懂面向对象和具体程序设计），只需要Focus数据库本身即可，经过分析存储过程，跟踪调试数据库纪录，往往可以解决问题。（曾经有过仅对一些特定语句的调优直接导致操作耗时下降了一个数量级），事实证明，这样是行之有效,代价最少的方法。越大的系统，越大的公司这样的好处越明显。

其实对于楼主的问题，也许根本就不需要重新设计，资深DBA/数据库性能调优人员出马就可以解决问题。这就是资深DBA/数据库性能调优人员的价值所在。同样，这也是对于大型系统，很多公司的首选。
毕竟对于一些大型系统，稳定压倒一切，不可能随便就修改某一部分的代码，毕竟这样往往会引入新的风险。