SQL 处理业务逻辑优于 Java 处理业务逻辑吗？感觉总是被业务负责人鄙视

[lh934275738]

因为现在项目数据处理量比较巨大，他以前是程序员，我感觉他希望我写的功能，全部用 SQL 处理，他觉得 SQL 的速度是最快的，导入的时候有个数据校验，因为比较复杂，情况多，这种，我选择用 JAVA ，今天因为谈到这个逻辑，我说出来，他说，你怎么以前不说，现在才说，说我这个处理数据最起码 10 分钟（一定要我用 SQL 分出情况来，我的天，我得写多少个 UPDATE 进行情况分类），结果 18S 以内还是本地机，服务器应该 10S 左右。我现在很多业务逻辑都用 SQL 处理，我非常不喜欢这种处理方式。
求解 SQL 处理业务逻辑优于 JAVA 吗？我觉得不优于，但是我们这边的业务负责人总是认为我刚毕业，结果我们部门来了几个所谓 3 年-5 年的，真心的，改前端复杂的请求修改，都是我找到方法，后端关于框架的一些问题基本上都是我解决的，也不是什么很难的问题，但是我真心超级烦
连续走了 3 个技术负责人，其中 2 个都是和业务负责人有矛盾，当然 2 个技术经理也是有点技术不过关或者情商不够，所以根本没有技术负责人和他将技术，他总是按照他很多年以前的技术来认为 JAVA 很垃圾，速度慢， CPU 占用大之类的

[Sharuru]

连续走了 3 个技术负责人，其中 2 个都是和业务负责人有矛盾，当然 2 个技术经理也是有点技术不过关或者情商不够

推荐楼主把 3 个变成 4 个。

[lh934275738]

@Sharuru 没有技术负责人了，因为我们属于乙方，类似于外包，但是比外包好一丢丢，走了一个之后，后面连续跪了 2 个技术负责人，直接就不招技术负责人了。因为公司部门合并，本来借调，结果变成转部门了，待遇相对来说会好一点，但是我是一定要走了，我真心受不了这个业务负责人了，一直在找工作，想找那种可以安心做 2 年以上的那种标准找的，结果发现根本没有面试，发面试邀请的基本上我都不想去，蓝瘦，现在只想换家互联网公司了，今年投了这么多简历，好不容易有一份面试，降工资就降了，后悔当时的表现了。

[liprais]

标准答案不是看业务场景么

[zacard]

恰恰相反。 sql 中尽量少的逻辑，甚至有时候一个 join 都需要拆到 java 中先业务处理，然后写成 2 条简单 sql 处理。
原因如下：
1.业务逻辑都在 sql 中，数据库将成为瓶颈。且数据库做分布式集群是比较困难的。而业务系统就相对更容易做分布式集群处理。
2.简单多条 SQL 的效率可能远大于一条连表查询 SQL ，详见 MySQL 权威指南等书籍。
3.业务逻辑在 java 中，能够保持扩展性、容错性等等，而 sql 中，连迁移数据库都是件头疼的事情，更别提扩展了。

。。。等等

[shoaly]

越复杂的逻辑越应该从 sql 里面剥离出来, 放到代码里面
先不说效率问题, sql 长代码一时爽 日后维护的成本太高了

[ivvei]

这东西得看，不能一概而论。跟业务，跟数据库本身，都有一些关系。

[linfeng123]

fsadf

[lh934275738]

@shoaly 维护真心要爆炸，还好现在又简了需求，之前因为加了个需求并且是需要分组的，结果有一个很小的一个方面没考虑到，炸了

[lh934275738]

@zacard 虽然我现在对 SQL 很反感，但是还是觉得 SQL 处理有些逻辑还是可以用的，跟 @ivvei 他说的一样

[hand515]

到时候天天整理慢查询 SQL 就蛋疼

[zacard]

@lh934275738 项目小，不复杂，你写那里都无所谓。

我们这个是入开发手册的， sql 运算、逻辑都不允许。简单逻辑你直接 mybatis 里处理，别放 sql 里啊。 sql 里不能有逻辑，我觉得应该不论什么情况都是正确的！

[aheadlead]

从某种角度说， CPU 能跑满也算是个好事，毕竟没卡在 IO 上…

[huiyue]

如果业务逻辑简单，且在可以预见的几年内不会出现性能上的担忧， SQL ，存储过程写多复杂都无所谓的。
如果可以预见未来需要分布式，需要对性能进行考量，需要对业务逻辑进行平凡修整，还是在代码里面比较好。

[weizhiyao008]

高计算量的放 JAVA 里面挺好啊，高 IO 的放 SQL 也不错。。。看情况吧

[Infernalzero]

4 楼已经把能说的都说了， LZ 你看着办吧

[0915240]

我们这边也不允许 SQL 中有逻辑。包括存储过程、触发器等。

[jybox]

- 如果是对数据的约束，更适合放到 SQL （保证最终的数据符合约束）
- 如果逻辑复杂到难以用 SQL 表达，更适合放到应用（毕竟 SQL 表达能力不如通用语言强）
- 如果是 IO 密集，且必不可少的工作，更适合放到 SQL （减少传输量和对数据的反复扫描，但前提是这个工作「必不可少」，不能因为放到 SQL 中来做而增加无意义的工作）
- 如果是计算密集，更适合放到应用（应用更容易进行横向拓展）

[yangqi]

sql 能处理的一些简单逻辑肯定是比查询完出来处理效率要高的，不过具体的肯定要看场景来定的

不够确定就是 sql 的里面的逻辑不容易测试和调试，所以不用也没有问题，具体还是要看情况。

[AccIdent]

@aheadlead 然后写个 while(true) {}?

[jsou]

业务逻辑一定要尽可能不往 sql 里放。
调试，兼容，分布式，可维护性，扩展性...
我觉得在这一点上不存在“分情况看待”的必要。

现在对数据库使用的主流方向是只用来存储数据，越来越多的项目都强制规定对于像存储过程、定时器、触发器都不允许使用。甚至外键都不允许使用。

如果要问为什么不用，请先问为什么要用，数据合理性在业务代码层面就要得到保证。