业务逻辑的定位: 向java走，还是向数据库走?

当开发中的业务逻辑既可以在数据库中完成（例如，使用oracle的function）,也可以在java的service层中完成时，我们应该依据什么样的标准来进行选择?各自可能的优点和缺点有那些?

按照我的逻辑,数据库大多数情况下只是用来存放数据的地方....如此而已....

支持数据库的观点是效率。认为存储过程的效率比程序代码要好。但是存储过程最大的缺点是不好维护，传统的过程式代码很难维护。而且SQL语句有时候有限制，不能很好的处理业务。
支持程序处理的观点是代码灵活，效率也不低。可以灵活处理各种业务。但是读取数据库的数据量比存储过程多，所以有人认为效率比较低。不过通过缓存等技术可以提高效率。

楼上两位说得都有道理

个人倾向于将业务逻辑放入Java代码中，表现层－业务逻辑层－数据访问层的经典划分还是很有道理的，尽管实现起来稍嫌麻烦，但在高并发的情况下容易扩展

我们为了效率，大多用存储过程
不过说起来，存储过程真的不好维护...

看情况，但一般情况下，我很反感把逻辑代码放数据库里

可读性可测试可维护性都比较差
倾向于 除非对性能要求极其严格或者接触不到逻辑的情况下再用
但性能问题可以通过缓存来比较好的解决
海量数据的时候，再怎么存储过程也没用

sql的语言表达能力跟java差太远，面向对象与解耦就不用提了
更不要提java的库函数.开发效率跟java也不能比

用java，在单元测试来的保证下，重构维护和理解逻辑都较方便
放在存储过程里，实在是受不了

我正在维护一个遗留项目，问题多多，逻辑混乱
偏偏把所有逻辑都用存储过程实现，最简单的增删改都用，让人发疯

和我今天早晨的问题一样

我的理解：看具体的业务操作的需求，如果对以后的功能扩展与改动不频繁的话我推荐使用存储过程来解决，反之如果业务相对较复杂，对系统的灵活性上有要求的话就应该采用java程序在service层来处理会更适合些。

补充一下：

其实这两种思路并不是绝对冲突的，可能在某个地方使用一种方法比较合适，在另一个地方使用另一种方法更合适

举一个例子，在我做过的一个项目中需要为各种单据根据单据类型、年份、部门生成单据号码，规则为单据类型编码+年份+部门编码+流水号。使用了一个表来保存每个单据类型编码、年份、部门编码组合的当前流水号，每次生成一个新的单据号码则把流水号加1。这个过程有几个特点：1.多个同类的请求同时到达时需要串行，否则单号可能重复，这需要在处理过程中不能出现脏数据，并且处理要迅速；2.逻辑清晰、不复杂，粒度比较小；3.是个公共的处理，各种单据都用得到。使用存储过程来做就比较适合，在业务逻辑层中调用即可

太极中的阴阳调和

不是service就能做一切事情，也不是存储过程就是万能的。