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

在O/R Map和SP之间还有一个，就是通过程序完全实现数据层的操作。

所以这应该是两个比较：
1、O/R Map vs. 自定义的SQL编程
2、可移植的标准SQL代码 vs. 绑定特定数据库的SP

我个人的选择是自己来实现。而不是ORM，也不是SP。

这样的观点我很同意，但是这样的话，hibernate的地位何在呢？

庄表伟
其实这并没有动摇hibernate的地位,只是把它和DAO一样放在一个单纯的数据库与业务模型的中间连接环节.

昨天翻了一下《Expert One-on-One J2EE Design and Development
》，Rod Johnson对sp也提出了自己的看法。系统开发存在一定比例的sp未尝不可，对于大数据量的更新等业务谁都知道比or实现好的多，而简单的增删改则正如ajoo所言“存储逻辑相对简单......o/r毕竟可以帮你自动生成很多代码"。同时我昨天思考了一下：感觉sp就象是过程化开发一样，而o/r则是面向对象开发；面向对象用烂了可以达到面向过程的”效果“，而面向过程用好了也很难获得面向对象的好处，但并不是说面向过程没有用，国内外用c、cobol开发的还是挺多。

这种o6z的方法我也用过，我写过一种只控制数据读写原子性操作的小框架，当时不是OR做到，是拿ADO.NET用C#写的，ADO.NET操作基本数据什么的非常方便。
然后我用了一些存储过程和触发器来管理业务逻辑，这样我的程序就被我认为扩展了一层，数据源字段修改只要不涉及到业务逻辑就直接在页面和DAO去做。我觉得效率也还是很不错的，而且扩展开发过几个小东西都效率很好。
我觉得小规模用这种东西还是有一定的好处的。

withouttea
把你的书继续看下去,就知道我们的讨论时多么幼稚.其实Rod Johnson对这个问题已经说得够清楚了,也就是不同的逻辑放在不同的地方去解决.重点看看第七章.

就我个人认为就这里人们讨论的基础而言（开放大量不同的商业应用），SP应该完全被抛弃。而原因也不是移植性（一般数据库在项目开始的时候就是确定的）。但是当我从开始意识到移植的问题后，我就很反感sp了，这仅仅是一种感觉，深沉次的原因我想是骨子里的“懒惰”。
    比如constraint,比如casecade delete，这些东西的确数据库已经完成的很好。我开始知道有触发器的时候还没有什么实际项目经验，觉得这个东西真是好啊，对付一些简单的需求的确可以省很多的劲。
    但一旦进入较大的项目，你就会发现事实根本不是那回事，是这些东西不够强大吗？显然不是。以上的涉及到这些功能难道仅仅出现在数据库的接口上吗？显然也不是。正因为这样，数据库虽然可以保证数据的完整，却保证不了程序员的工作的完整性，说到底，这些东西并没有解放程序员。甚至因为程序员要同时关注多个方面，反而加大了负担。使用中，sp就和脚本语言差不多的感觉。
    那么为什么还是有公司，有人推荐使用sp呢，据我所知，不仅是我们，一些大公司也是如此做的。但原因其实不是SP和O/R或者其他什么的比较上，而在于工作的分配上，因为逻辑放到sp中完成，自然就是一种强迫的分层和工作分派，而sp程序员的工作也显得非常直白-每天大量的反复的sp书写。但对于程序员而言真的会喜欢这样吗？我想在座的每个人都会有自己的计算。
    SP功能是高于O/R的（不会有人用sp只是简单的存一下数据，那样如上所言，头儿那边肯定也过不了关），拿O/R比较SP，实际是面向对象设计和使用数据库脚本编程之间的比较。实际上说到底是我们这方面的功底是怎样的，就个人感觉而言，前者的空间比后者大得多，也就是对程序员的潜在回报可能远远高于后者，这也就是我这个“懒人”的感觉。

o6z随口所说的，withouttea别往心里去，大家都来讨论嘛
我想他是希望你深入了解那本书的后面章节，不断章取义嘛

谢谢 mikecool  ！ 人还是要宽达一些好。 那书后面的章节我也看过， 我知道 Rod Johnson所论述的重点是什么。但这个话题大家还是发表了自己的看法，我也有了新的认识，只是希望大家别只从一个方面看待问题。

老大们，你们谁见过业务有了变化，而相对应的数据结构没有变化的。
就我的经验来说，我认为把业务逻辑用SP来实现比较可靠，稳定。
在说SP的移植是很容易的。说SP的移植是困难的是因为他没有把所有的业务想清楚了。