关于存储过程的使用

刚刚结束了一个电信方面项目，DAO用的Hibernate，后来因为效率问题，在不断优化的同时，有的地方就开始用JDBC、存储过程。在系统测试过程中，还是基于性能上考虑，开始大批量的用存储过程，开发人员每天的工作由写JAVA变成写SQL，存储过程中封装了N多的业务逻辑，我很担心维护与移植问题，但上线的压力与实际性能上的压力让人没有更多选择。
不知道大家在项目中对存储过程使用是怎么个样子，存储过程用是要用，是不是有个度？
plus：这个项目库表结构复杂，数据量很大。

所谓的移植问题纯是脑子锈斗了。
移植产生的费用够卖三四台服务器+oracle了

只有做产品才考虑移植，做项目没必要考虑移植。

等到项目真有移植需求的时候，就是一个新的大单来了，市场部的会开心死。而这个时候指不定你早就不在这个项目或不在这个公司了。

我一直不想写存储过程，去年经历过从oracle向sybase的迁移，乱的很。
项目的实际需要有时很残酷，它可以让既有的设计变的苍白....

刚刚上线的这个系统是我们去年开发的一个产品。这个项目是该产品的第一个实际应用，由于需求做的不是很充分，后期问题很多。

项目型的系统好像都不太考虑移植的问题，我们现在的系统就是将业务逻辑写在存储过程中。很大的原因就是要控制客户，搞得越复杂，以后维护费用可以收得越多。

大量存储过程的系统最大问题在于维护

如果实在要用存储过程了,那么由专人(最好是DBA)来编写和管理存储过程

不知当初的领域对象是如何设计的。如果发生你说的这种情况，有很大可能是领域对象设计有问题。还有，Hibernate是否使用了缓存？是否在表现层和Service层也做了缓存？
还有，压力到底有多大？是否应该使用集群？这些都需要考虑。如果全丢到数据库跑存储过程的话，会要了数据库的命的。

如果存储过程可以减少客户端和服务器端的数据流量和减少查询的次数。那么还是可以考虑的