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

楼主怎么就这么倒霉？不就是说了实话？

只能说明一个问题，sql很吃力，或者sql很一般，为什么能在java中过滤就不能在sql中过滤，数据库自操作速度应该是很快的了，只能是你们原来的存储过程写的很烂，建议LZ在sql上多下点功夫

LZ，我支持你啊。虽然经常写sql,但却很少写存储过程，原因是不太懂。现在java里面有支持调用存储过程的Api。不过，也很少去使用。

分析楼主的问题，焦点集中在下面几点。
1.java能做的数据库查询操作是否存储过程都能做？
2.同样算法下一般存储过程是否会比java代码执行效率高？
3.存储过程是否比java代码难于维护？

我的答案是：
1.基本可以。
2.是。
3.是。

基本结论就这样了，楼主就是没经过太多验证就放出一个结论，到此为止吧。呵呵

这论坛看来什么人都有 这个帖子某个人看起来极其让人不爽，请自重

这种事情可能发生吗？ 除非你的存储过程写的很糟糕！
听上去酒店n大才能发生这种情况。假定酒店有1000个房间，每个房间每天产生100条相关数据，写存储过程每天算，估计最多1分钟。

同意楼上的观点，lz没有对症下药。
存储过程的调优是比较艰辛，需要耐心。
例如，在我现在的这个项目，做数据抽取，以前用java代码做抽取，300组记录(包括主表，子表)，这还其中涉及了许多统计，需要20分钟以上，客户天天投诉。后来将全部java代码改成存储过程，并对每个sql语句都进行调优。最后的效果是300组记录的数据抽取，存储过程只要400多毫秒就完成，如果算上其他的损耗，整个过程也不超过2秒。客户对这个结果非常满意。

要说效率为什么现在没多少人用汇编和机器二进制码去做，这个道理大家都懂，某些人不要因为自己sql怎么怎么好就说楼主这样那样不行，我看楼主说的基本都没什么太大的问题。

1.任何一个项目的资源都是有限的，不可能今天需要存储过程高手，公司里就冒出个存储过程高手来编代码，如果他跳槽了，谁来维护，花很少的钱再去找一个，你去招招看。

2.sql作为一种面向过程的dsl语言，在某些方面不如面向对象的语言，很正常么，尤其是在JVM的帮助下，Java当然可以非常高效，楼主都已经说了他们的业务逻辑的特点了，有些人还在强调什么算法，算法是业务逻辑么？

3.sql和一些特殊的sql语句无非就是对关系数据库的操作和优化操作，但是一旦这些优化的命令和操作对现有的的复杂业务逻辑计算提供不了太多的帮助，计算效率下降，代码量成倍增加，可维护性就会很差，维护人员时间成本（包含工资成本）就非常高。

4.楼主也说了，有些逻辑（其实就是适合用sql来做的）会考虑再次放到存储过程来做，说得很好啊。

5.有一位网友说的也很好，很多时候数据库就是瓶颈，扩展的代价远比扩展应用服务器昂贵和复杂，根本就不应该占用宝贵的数据库资源做业务逻辑操作。

再次说明，存储过程很强大么？怎么不去写操作系统或者是httpserver呢？有多线程么？有分代垃圾回收么？有清晰完整的内存数据存储模型么？
特定的DSL语言就是做特定的事情。

你成了另一个LZ.
只是方向变了。