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 里放。
调试，兼容，分布式，可维护性，扩展性...
我觉得在这一点上不存在“分情况看待”的必要。

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

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

[forestyuan]

@jsou 这个就太极端了，就算业务代码层面就要保证数据没问题，在数据库里多一层限制 /校验有何不可？

[ncisoft]

传统企业级应用和互联网应用是非常不同的技术处理路线，露珠对数据库很熟吗？达到 dba 水平没？别提 MySQL 这个垃圾，至少也得是 Oracle SQL server 这种企业级数据库

[ivvei]

@jsou 业务逻辑放外面也就分布式上占点优势，其他谈不上特别的好处，反而是开发人员自身背景和偏好的影响更大些。

[ivvei]

@zacard 那只是你们的开发手册。要说逻辑复杂，金融, 电信，这两个行业是 sql 使用的重灾区，难道属于业务逻辑简单的类型？

[ncisoft]

我以前帮一个项目优化性能，有一个小伙子是搜狐出来的，动辄就是我们在搜狐是如何如何做的，如何如何地快，分表分库缓存一堆巴拉巴拉。最后我帮忙设计的方案完全没用互联网企业那套，他那套方案连评审都过不去，无他，业务场景不同。 MySQL 这么垃圾的数据库也就互联网企业敢用

[yangqi]

@jsou 业务逻辑也分前端业务和后端业务, 不同行业差别很大, 肯定要看情况的

[ericls]

做 benchmark 看看？

[akira]

@jsou 非常同意你的观点。存储过程、定时器、触发器 个人建议能不用尽量不要用。

业务逻辑尽量在代码里面完成，数据库这边尽量不要涉及业务逻辑，这应该是一个基本要求吧。。

[loading]

程序可以很容易知道操作是不是并发的，数据库我可不知道，万一锁表了那就堵塞了。

[linbiaye]

懒，不想自己做。

[sun1991]

对传统企业级业务逻辑来说：十几年后 SQL 还是那个 SQL ， Java 或许面目全非了（语言，框架， IDE 工具等等）。不过 SQL 写逻辑一坨一坨垃圾一样的代码，复杂点的更是写的想死。

Java comes and goes, but SQL stays forever ;)

[zacard]

@ivvei 重灾区并不能说明其是合理的。银行与电信重度依赖 sql 更多的是因为早期系统更多的依赖动辄百万性能强劲的小型机和 oracle 数据库，这在当时的性能确实比 java 虚拟机中的程序来的快。

[suikatw]

我司也是重代码逻辑，轻 sql 逻辑
真的需要性能的情况下都是直接打 mysql 的 patch ，特定场景专门优化

看到有同学提到了存储过程，我想了解下存储过程的版本管理是怎么做的，以及存储过程的版本管理怎么与代码的版本管理结合

[ivvei]

@suikatw 存储过程也是代码，代码怎么做版本管理，存储过程就怎么做管理。把存储过程弄到生产数据库里编译，那是代码发布的阶段了。

[dexterzzz]

请用上企业版的 orcale ， sql server 了再来说数据库性能，功能。

[xiaochong]

四楼是对的

[killerv]

sql 中最好不要涉及业务逻辑，看场景，能拆就拆， join 、子查询的效率并不高，甚至有时候低的夸张

[wupher]

业务负责人是从 Windows Client 年代传下的习惯。那年头的架构习惯是：展示及交互使用 VC/BCB/Delphi/VB 来编写；业务模型及逻辑使用 SQL 存储过程及函数来编写， Client 处理逻辑时直接调用 SQL 过程。

之所以这样玩，第一是方便重用和调试，那时 Client 经常版本众多（特殊版，某地修改版，一个管理系统全国铺开，上百个个性化版本很觉见），但是后端逻辑相对稳定。第二是现场救火时处理，发现由于逻辑或者数据造成的问题，直接去 SQL 服务器上改脚本就可以了，否则重新编译打包分发个客户端出来就麻烦多了。第三是多客户端同时连上时，直接使用数据库来处理 transaction 和并发数据冲突。

缺点是很多的， SQL 脚本写的逻辑，年数一多之后，简直让人发晕。相对于编程语言，很多逻辑处理，使用 SQL 来实现要麻烦，可难维护的多。如果用户量上来，想将计算可扩展， JAVA 只要部署一堆进程，使用 http 分发即可。分布式数据库可就折腾和花钱了。

总而言之，这是门相对过时的架构设计方法。当年做 Delphi ， VC ， VB 是这么干，并不意味着几十年过去后还要这么干。

[YzSama]

SQL 和 Java 的市场需求不同。
看市场，使用 SQL 会比 Java 多？
在 SQL 里面写了一堆逻辑，这不明显增加维护成本？
明明可以招个写 Java 的进来写业务代码就好了，现在偏偏要招 SQL 人员来写。
后者需求少，价格明显也比 Java 高。

[powerfj]

sql 的维护成本 相比 代码来说应该会高

[jadetang]

这个看需求的，一般来说，互联网项目会依赖数据库比较少，很多业务逻辑都在应用层面做了。但是传统企业的项目，技术架构就没有那么先进，采用的多数是， Transaction Script

https://www.martinfowler.com/eaaCatalog/transactionScript.html

这种模式扩展性会比较差，但是有一个前提是你的业务量达到了需要扩展的那个点。

[tabris17]

这个问题可以简化为：《业务负责人是傻逼怎么办？》

[Aksura]

看你需求的类型， OLTP 的业务逻辑只要不涉及事务的，尽量在程序里维护； OLAP 的业务逻辑你不用 SQL ，数据正确性、一致性这些你自己程序维护，时间稍长都是坑。

数据库性能这个，如果只用过 MySQL ，真的就不要提了。

[PoetAndPoem]

@Aksura 感谢。不过很疑惑什么样的软件可以被称为 OLAP，涉及到数据分析模块的软件吗？