业务逻辑写在java里还是写在数据库里

Question

最近读Oracle编程艺术，作者建议将业务逻辑全部写到数据库里，Java只是作为一种扩展使用。作者列举出了这种做法的种种好处，但是作者作为一个数据库专家，本身对待技术上可能就有倾向，况且这又是一本关于Oracle的书。

我现在想知道，将业务逻辑写到数据库和写到Java里这两种方法的优缺点各是什么？之前搜索到的答案都是“我是写到XX里去的”，“我觉得应该这么做”，但是没人给出具体的原因，有的原因也像作者这样，只给出了自己这么做的优点，对于分析不同业务场景的意义就局限了。谢了各位先~

Answer 1

我们目前写载数据库里，感觉只要用java写个工具类，业务写在数据库里快。几乎不要些什么java代码。好处就是开发快，感觉也不难，缺点就是换不了数据库。

Answer 2

业务写作数据库里会增加数据库的压力，不易维护，易出问题，出问题了直接在数据库里捣鼓，不小心数据搞丢了，搞坏了呢？容易造成严重的事故，这样对数据库人才要求特高。 业务写作程序里有些涉及到事务、锁、定时要求准确，应用程序多处处理或分布式的啊等这样会给程序维护造成极大的麻烦，一个业务往往要多出维护；有时处理一些大量的数据，对数据库和应用程序都是个负担，大量的读取大量的更新或插入，而数据库往往存储过程游标一些判断等就能轻易搞定，我们还要程序来处理吗？ 我觉得结核公司的情况(要求高点，这样有动力嘛)，业务流程和要求，系统架构(想远点)等因素一起考虑应该大概能找到哪些放在数据库比较好哪些放在应用程序比较好了吧？ 以上是个人的一些愚见，多多指教！

Answer 3

是的，但我想知道的是这二者各自的优缺点...除了概率很小的切换数据库外，TOM大叔没有提到业务逻辑写到Java中的优点，毕竟他是在写一本Oracle书，所以我对此感到疑惑。但按照你的观点，的确在很多场景下，我们得根据自己团队的能力来决定到底是写在哪儿，多谢指导~

Answer 4

TOM大叔是oracle第一牛人，同时他也很精通Java，他的很多观点还是很值得我们思考的，我觉得如果团队里有比较多人是熟悉数据库的话，业务逻辑放在数据库里是比较好的选择。