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

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

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

1.要看你对存储过程的驾驭能力，如果一般，确实未必好。

2.确实是废话。

2.不是“有时”，是大多数情况。如果你是程序员，不是DBA,基本会希望在代码里看业务逻辑。

 

我想存储过程的问题，大部分人是有定论的，就是“除非性能需要，业务逻辑不放存储过程中”。

例外的情况也是有的，我现在手上的一个项目业务逻辑基本就是存储过程，包括很简单的添加，删除，修改。没办法，当时做这个项目的人，在写程序技能上很差。

 

楼主勾出了性能优化问题，却不拿出足够细节，让此帖失色。

我感觉，这只能说明你们那个存储过程写的太差

应该不是存储过程问题，
ORACLE ERP 业务够复杂吧，
但业务逻辑基本上都是用存储过程实现的，
个人感觉应该是设计或代码写得不完美。
个人平时使用存储过程感觉还行。
仅供参考。

我们没有比较好的DBA，只能说尽量去优化。事实上存储过程最初没有这么慢，但数据库的数据和参数设置都在变化中，性能也是一点点变的不好。
这也是我们把业务逻辑拿出来的一个原因，存储过程这次调优好了，数据变化可能慢慢使性能差了。而程序基本上调优后，变化基本上只好数据量有关，优化的手段也多。
另外使用存储过程，也并不是说程序中就没有业务逻辑了，程序和存储过程的结合过程不好，整体性能也比较差。
之前的程序，存储过程是处理一天的数据，程序是循环调用。



事实上我们也考虑过缓存，一方面目前的性能够用了，另一方面客户要求是实时的。

代码层的优化，大都在某个点上（如某些条件的过滤）。而存储过程的优化，通常是在某个面上（如实现归并的算法）。

你那些对象也只是jdbc、sql抽出来的

你讲一下，你在Java中优化的哪些点，是在pl/sql中不能做到的。

（如某些条件的过滤）？？？

不是说不能做，而是麻烦或性能不好。
比如说，有些数据记录是不规范的，代码中就可以把规范检查的动作放在某些类中。而存储过程怎么做呢？把数据记录都放在临时表中，把不规范的数据删除掉。
对于过滤是如此，对于某些业务逻辑也是一样，比如：如果供应商不是酒店，要从另一个价格表中取数据。
具体的点有很多，只是想说明：程序优化的方向和存储过程优化的方向不同！

哪里麻烦，哪里性能不好。

为什么你在Java里可以用代码检查，而到了pl/sql里就需要用到临时表？

你举几个明确的修改点出来。