请教高手:我应该选择数据库还是java来处理业务逻辑?

我在做一个J2EE的接口程序开发(oracle 9,weblogic),有一个逻辑是将某个业务表里面

的数据取出来,封装为JMS对象发送出去。
从业务表取出的原始数据,要做一些处理,根据其它配置表做一些逻辑处理,得到正确的

结果。
取数据是在用spring JDBC 做的,直接放入一个bean对象里面。
现在我要改业务逻辑。就有两种方式。
1。直接改SQL或者用视图的方式,取到正确结果,这样java方法就不用改。
2。新增或者修改取数据的java方法,不依赖数据库。

我在这两种方法上犹豫不绝,依赖数据库究竟是好还是坏。如果改SQL,用一些9i提供的分

析函数,case 语句最终得到复杂的结果,目前工作倒是简单了,但是好像造成业务处理分散

。而且如果需求进一步扩大,1条SQL就可能就无法实现,而且单条SQL业务可读性差。
而在java里面做,总觉得多此一举。该系统性能要求严格,再次用过JDBC来处理业务逻辑

,虽然思路清晰,扩展性好,但又觉得不如数据库性能好。
请各位经验丰富的专家,解答我这个菜鸟的疑惑。

现在Java多层分为表现层 业务层 和持久层。

业务层就是处理业务逻辑,按照DDD理论,分为应用服务层和领域层,典型的DDD系统,数据库层基本是模型的持久化,也就是基本CRUD,如果你试图想在这些基础的SQL语句中加入更复杂的SQL组合,那么你就可能开始将业务逻辑写入SQL语句。

多层DDD带来好的软件质量,可维护和可拓展性,这是主流发展趋势,所以必须摆脱那些数据库仓商的误导,坚持以OO思维来设计软件系统。