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

不过移植基本是个伪问题。
一个运行一断时间后的生产系统，只要还能凑或，没人愿意去移植数据库。就像前面那位哥们说的，出了事情没人扛，找这个事干吗。
我见到最多的"移植"，是系统整个重新实现之后怎样把以前的数据导入到新的库里面去。此时如果更换数据库平台，这个成本比较大。但是，这个并不是这里的关键，困难在于前后实现之间数据表结构和关系本身就有很大的不一致性，从而数据导入规则就比较困难，而且，不要忘记磁带上的数据。
对于生产系统而言，应用保持不动而切换底层使用的数据库，只是一个噱头。
唯一可以考虑移植性的，是开发系统和生产系统之间的数据库切换。此时，数据可以丢弃，怎么着都比较容易。

真没有到，又回到了这个话题。

我就不讲移植了，其实也正如大部人说的，数据库不经常换(所以也要注意一点，如果客户是oracle，你就得用oracle的sp脚本来写，如果ms sql server 就要用ms那一套，如果是XXX,就要用XXX来写，你不会叫客户买一个新的数据库吧(我们只会oracle的sp)，然后又用一台的服务器？当然也有可能的，嘻）

综上面所说，大家都只讲了开发部分，不知道大家有没有想过布署项目的事呢（如果只布署过一次，就从来都没有修改的那种，就不要看了）。

假如：我布署好了项目，过了一段时间，因为有一些地方要修改（不要问我原因，客户会用一千个理由说服你，或者强逼你），如果单单只是改一下程序逻辑就算了，但如果还联及sp呢？首先要布署程序，然后再布署你的sp（什么？你的sp包括了业务逻辑，那就当我没有说过吧），觉得怎么样，麻烦吗？

其实一开始写sp的时候，几有瘾，不过频繁的修改与布署也是很麻烦的。所以现在的项目除非必要（有人说过了理由，我就不重复了），否则我都不会用sp。

更改实现后部署sp不会比部署程序要难。只是部署的地方不一样。一个在应用服务器上部署，一个在数据库服务器上。而且，给我的感觉，sp要相对容易一些，对应用的影响也小一点。

可惜对软件公司来说，移植并不是一个伪问题

你做了一个ERP，当然你可以强迫所有人用ORACLE，但是有些人偏偏愿意用SQLSERVER或者用SAPDB,你怎么办

做产品的话不一样。移植性可能可以通过orm来实现，但产品所需要的性能优化能力，仅仅使用orm是很难达到的。
现在看到的erp产品，都是有着一大堆sp的，不同的数据库平台有着不同的sp，或者这个可以称作sp的localization? sp的好处是可以找该数据库平台上专业人员来特定优化某一些sp，而不需要涉及到程序。
一个好的java开发者未必是一个好的数据库管理设计人员，而一个专业的数据库技术人员对java地把握程度就更难说了。

你看的到ERP产品就是公司为每种数据库配备一个开发团队。然后每次产品升级，各个不同数据库平台的团队要一起参与开发，协作，测试......如果需要把ERP产品延伸到一个新的数据库平台，于是再配备一个新的开发团队进来......

嘿嘿，即使是MS，也不会在一个产品上投入这么多人力和成本的。

如果体系结构设计的不错的话，每个数据库平台版本的开发团队只是一堆该平台上的技术专家，只做平台适化。不用orm，未必就做不到数据库层的隔离，这里只是一个抽象程度和性能的权衡。
不过，正儿八经的ERP厂商都有自己主推的一个数据库平台。对别的支持就差一点,hehe。

SAP就支持很多种数据库，致使有些麻烦而已，主要是Oracle所以他自己的SAP DB也是以兼容Oracle为主

ORM在一定程度上极大的降低了对数据库特性的依赖性，这点是毋庸置疑的

有谁见过业务繁忙的系统移植数据库的？麻烦介绍一下。实际的经验可能更有意义。

我对于业务繁忙是这样理解的：
满足以下一个或多个条件的系统
1。数据库查询在1,000,000/天以上；
2。数据库更新查询在100,000/天以上；
3。总用户在100,000以上；
4。活动用户在10,000以上；
5。事务在100,000/天以上；
6。如果是b/s应用，pageview在200,000/天以上。

这些定义是我自己估计的，自然有不准确的地方，还请指正。