业务逻辑是放在 Java 好还是放在 sql 好？

[zw1one]

如题~

[lueffy]

代码里吧

[jay0726]

业务逻辑放 sql 是什么操作？没见过啊，恕我孤陋寡闻了，告辞。

[leonme]

业务逻辑能放在 sql 里的一定是高手～ 2333

[SilencerL]

@leonme #3
@jay0726 #2
你们是没见到大部分业务逻辑全放在存储过程里面的
每次加新功能或者 Debug 的时候我都要由衷问候上一任开发者全家的那种

[maxiaofeng]

sql 中写业务，除了你自己，别人是没有办法维护的。 数据库的压力也要考虑

[zw1one]

@jay0726 比如说我要查三个表然后做一些处理，再把处理结果展示。我查了三次数据库，然后用 java 处理。这时候有人告诉我说，我这么查数据库是很浪费资源的，直接一个复杂的关联 sql 把业务处理了，说就应该这么写。

[xbigfat]

我认为放在 sql 里面好一些，相对的查询速度快，不用暴露 sql 到程序中去，对于客户端软件大有益处。我现在写的很多都是 PLSQL 里面的，有问题也好改，不用重新更新客户端

[lueffy]

@SilencerL 我们公司直接规定 不准用触发器 /存储过程 /视图 外键约束都不让用
连物理删除的权限都没有

[night98]

@xbigfat 第一次见到 2019 年还有客户端直连 db 的。。

[xbigfat]

其实，好像 oracle 官方也是建议这么做的，在 plsql 的说明里面，写了不少这样做的好处

>https://docs.oracle.com/cd/E11882_01/appdev.112/e25519/overview.htm#LNPLS0121

[xbigfat]

@night98 呃，我不是这个意思，我的意思是，总有一部分的 SQL 代码要暴露出来，通过写入数据库的方式，所有的逻辑都在数据库中，库外的程序只要填参数

[whypool]

以前很喜欢这样写，直接调用存储过程
都是 sql 可以直接部到每个环境，还能用版本控制

但是，后来，自己写的存储过程都要看很久才能明白业务逻辑

数据库写业务真的难维护，注释写得再详细，都没程序代码好理解，能不用最好不用吧

[wysnylc]

十年前,随你怎么写
现在,你写 sql 就是找骂,而且不仅别人骂,未来的自己也会骂现在的你煞笔

[domty]

写程序里
等你业务量起来了需要做水平扩展的时候 接中间件就可以了

[lookatme]

题目里都带上 java 了，那基本上会遇到的所有场景都不应该把逻辑放在 sql 里

[felixcode]

不熟悉存储过程不代表这不是最佳实践吧？
存储过程还是有很多优势的。

[zhang77555]

复杂的业务逻辑还是写代码里把，简单的如果 XXX 则 XXX 这种，所有 sql 模板引擎都支持。能关联表出结果的时候一般关联表更好，不推荐使用存储过程，因为代码里不可见，问题追踪起来比较麻烦。

[karllynn]

存储过程维护成本比代码高多了…难以理解，而且 debug 很麻烦

[l00t]

看情况吧。放存储过程里不利于水平扩展，但是没有水平扩展的需求的话，放存储过程里也没啥问题。另外就是也要看数据库，有些数据库本身不太行，那么塞太多东西也会影响表现。

维护成本？一点也不高啊。存储过程这东西不是一目了然的嘛，哪有那么难读。

[huangdayu]

都是大佬