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

接触过这个项目，以前真的是用存储过程实现，程序倒是不用改，只是定义了很多优惠策略的配置点。

偶现在遇到这个问题了
比较了，体会了……sp不爽

我們公司自己開發ERP給自己用﹐SP占絕對位置﹐因此也培養了很多SP高手。
ORM﹐熟悉的人不多﹐所以現在要改新版﹐還是SP為主力。

软件要做成产品呢,sp还是少用/不用为好.
不得不说的是sp的开发效率要比java实现业务逻辑高不少了.
btw:
对于大批量的数据库操作,sp还是有用武之地的.

个人感觉SP和ORM没有可比性，关键还是看系统的实际需求，如果系统比较小，感觉用SP会好些，毕竟从执行效率，应用维护上考虑，对技术、管理人员的要求会低些，一个小系统不可能指望一大帮专业技术员为它服务，如果系统比较大，自然用ORM会合适些，这个时候系统注重的是伸缩性，可移植性，扩展性!

我们公司的业务高手都是写存储过程的，他们有些人就不大懂java
不知道会有什么后果

我是这样考虑的,如果为了提高效能我会用sp.当然维护成本会提高,还不能重用,提高了大家的学习成本(现在的公司是不用考虑学习成本的,因为学习成本都是在我们自己上,郁闷.).
用OR,当然有很多好处,但是用了OR就代表程序OO吗?如果程序不OO,我倒不如用SP

窃以为SP和Programming方式的好坏不是从纯技术角度就可以比较清楚的。从纯技术角度来说，SP性能高，Programming灵活。还有一个就是SP倾向于两层结构，Programming倾向于多层结构，也就是Programming一般可以引入Application Server这个层次，扩展性可能好一些。

上面有人提到把应用逻辑分成存储逻辑和业务逻辑，乍一听挺有道理，但是按什么标准区分哪？业务逻辑最终还不是映射成所谓的存储逻辑？所以这里面业有些不确定的东西。

我觉得它们的好坏应该从成本的角度考虑，设备购置成本，人员成本，时间成本。如果已经拥有了相应的数据库，同时拥有比较优秀的DBA，不引入Application Server也能满足应用的规模，我觉得SP并不是一个坏的选择，它的不灵活也不会是一个很大的障碍，几乎设想不出来它没办法表达的逻辑。

当然，如果我们很熟悉ORM等技术，同时比较关注移植性（我觉得这个关注一般都是没有价值的），同时问题规模比较大，分层次是比较好的选择，那就选择Programming方式吧。市场上也可以有好多噱头，未必就不经济。