业务逻辑分别用存储过程实现和用java数据存储（O/R等方式）...

所在公司主要开发金融行业的软件，后台几乎都是用sp实现，对目前流行的新技术or等不感冒。虽然本人喜欢新技术，但在开发过程中的确没有看到sp实现业务逻辑有让人无法接受的缺点，且调试、修改只需在数据库服务器上完成，比修改代码、修改配置、重启应用快捷的多。我所认识到的sp的缺点是移植性差、只能使用一个数据库。   请大家评论一下

等着看without EJB中文版吧,或者找本英文的看看.这个问题其实没有太多讨论的必要,存储规则用存储过程没有问题,但是业务规则要用存储过程来做,就太麻烦了,后期的危害性太大,可扩展性也差.

用存储过程实现数据存储是一个久经考验的方案,但对于一个大型系统,如果全部使用存储过程,那么数据存储的数量之多就不好把握,如果把一些对象的增删改操作改用orm管理,会大幅降低存储过程数量,另外把对象的增删改操作如何快捷映射到存储过程也是必须考虑的.

存储过程数量到不是一个大问题，且只要命名合理不会乱。我们以前也的确是用hibernate实现大部分增删改操作，复杂逻辑用sp，但是发现简单的增删改的sp很简单 顺手就写了，而且修改很快，相对来说hibernate要修改配置、java还要重新启动，这对于时间紧的项目来说没有优势，后来老板说不用o/r了 全都用sp 我也想不出好的理由反驳

sp和Hibernate是对等的概念吗？做这种比较毫无意义。

我没有说sp和hibernate对等，再说也不是只有对等的东西才能比较，同时我也没想刻意比较二者。但二者的确是目前存在的开发途径，老板对我说以后都用sp，我迷惑，才来请教大家的，无他

既然老板这么说你就这么做吧。一切的讨论、比较总是站在一个共同的基础上才能开始，譬如说要讨论OOD，如果有一方压根连面向接口编程都不认可，那么一切的讨论都将是毫无意义的废话。存储过程和ORM的问题，基本上也是同样的性质。

Gigix说得没错，不在同一个基础上不好比较
我觉得ORM和SP解决问题的目的就不一样
ORM致力于降低耦合度，减少对数据库的依赖，使开发聚集在对象化周围，不用过多关注持久化这些对象
SP的话，整个开发的方针政策和思路就不一样，他建立在数据库绑定的基础上，程序要过多的依赖数据库的实现，如果业务对象重构或者改变，改动就相当的大了

仅仅是我个人体会:)见笑一把

我觉得挺有意义的。
从实用主义的角度，从前用sp挺好的，现在要用o/r，总要给自己找一个充足的理由吧？
什么“认可”不“认可”？实用主义不考虑这些概念游戏。要用“oo”，面向接口取代面向过程，也需要找出一个“为什么”给自己做借口。不是一句：“oo和面向过程不是对等的概念，讨论没有意义”可以敷衍过去的。
我记得robbin好像也是推崇实用主义的吧？

withouttea给的理由其实很实在：sp改动方便，系统架构也简单得多，虽然有移植性的问题。


当然，这个比较可能不象1+1等于几那么容易分辨。也许类似讨论都已经滥了。但是，拿“无意义”来搪塞显得太牵强了。

mikecool说不好比，但是你的理由其实已经是一个比较了。

oz说的就更明确一些。我个人比较同意这个看法。实际上，拿sp做和数据存储关系不大的业务逻辑（可以对比session bean）很不舒服。
移植性不去说，至少，sp用的语言（比如t-sql，连异常都不支持）远不如java/c#这些强大好用，这种过程性语言写复杂逻辑从开发维护代价上来说很不经济。
而且，硬件角度说，用昂贵的数据库引擎和资源来做这些app server可以做的事情也不合适。


这是说业务逻辑。
对存储逻辑(类似entity bean扮演的脚色)，是用sp还是o/r呢？
我想这才是withouttea要问的吧？


我个人的感觉：如果数据库规模不大（表不多，如十几个），但是结构复杂灵活（存储逻辑很复杂），这种比较适合用sp。o/r相比之下灵活性可能欠佳。

而如果数据库规模很大（表很多），而结构，关系，存储逻辑相对简单（可以用简单的映射来处理表和实体的关系），那么用o/r较好。
o/r毕竟可以帮你自动生成很多代码，节省了手工写和调试大量很trivial的sp的时间。维护上也容易很多。

胡说八道一番，其实这个问题我也一直有所困惑。毕竟，为了虚无飘渺的所谓“移植”的可能性事先花费很大代价不见得值得。
（就象订飞机票，如果我知道自己不大可能改期，为什么多花那么多钱买可以改期的机票呢？）

我觉得还是多考虑用数据库自身的功能来解决数据库自己的问题,也就是把数据存储的逻辑都交给数据库自己办.首先数据库为了保证数据的完整性引入的各种约束机制我们可以很方便的使用,比如constraint,比如casecade delete.而且还有更强大的触发器.使用这些机制大多数情况下都比使用java代码来得便宜.
但是确实数据库之间的不同会给一些问题带来很麻烦的后果.这里不仅仅是移植问题,还包括数据库编程的细节问题.毕竟现在国内好的数据库DBA不多.