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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2817 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

SQL

Java

逻辑

业务

44 条回复 • 2019-02-19 10:57:24 +08:00

Sharuru

2017-03-06 16:55:07 +08:00

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

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

lh934275738

2017-03-06 17:17:39 +08:00

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

liprais

2017-03-06 17:24:39 +08:00

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

zacard

2017-03-06 17:34:36 +08:00

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

。。。等等

shoaly

2017-03-06 17:38:02 +08:00

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

ivvei

2017-03-06 17:42:00 +08:00

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

linfeng123

2017-03-06 17:43:58 +08:00

fsadf

lh934275738

2017-03-06 17:52:31 +08:00

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

lh934275738

2017-03-06 17:55:58 +08:00

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

hand515

2017-03-06 18:24:58 +08:00

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

zacard

2017-03-06 19:49:19 +08:00

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

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

aheadlead

2017-03-06 19:56:27 +08:00

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

huiyue

2017-03-06 20:40:10 +08:00

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

weizhiyao008

2017-03-06 21:08:58 +08:00

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

Infernalzero

2017-03-06 21:52:26 +08:00

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

0915240

2017-03-06 22:08:02 +08:00

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

jybox

2017-03-06 22:20:22 +08:00

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

yangqi

2017-03-06 22:21:39 +08:00

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

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

AccIdent

2017-03-06 22:37:47 +08:00

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

jsou

2017-03-06 22:39:10 +08:00

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

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

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

forestyuan

2017-03-06 22:48:38 +08:00

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

ncisoft

2017-03-06 23:18:33 +08:00 via Android

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

ivvei

2017-03-06 23:18:51 +08:00 via Android

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

ivvei

2017-03-06 23:22:43 +08:00 via Android

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

ncisoft

2017-03-06 23:26:08 +08:00 via Android

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

yangqi

2017-03-06 23:27:28 +08:00

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

ericls

2017-03-06 23:36:32 +08:00

做 benchmark 看看？

akira

2017-03-07 00:23:19 +08:00

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

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

loading

2017-03-07 06:52:56 +08:00 via Android

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

linbiaye

2017-03-07 09:33:56 +08:00

懒，不想自己做。

sun1991

2017-03-07 09:46:52 +08:00

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

Java comes and goes, but SQL stays forever ;)

zacard

2017-03-07 10:20:16 +08:00 via iPhone

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

suikatw

2017-03-07 10:54:11 +08:00

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

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

ivvei

2017-03-07 11:04:00 +08:00

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

dexterzzz

2017-03-07 11:26:57 +08:00

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

xiaochong

2017-03-07 12:21:22 +08:00 via iPhone

四楼是对的

killerv

2017-03-07 13:37:24 +08:00

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

wupher

2017-03-07 14:36:15 +08:00

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

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

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

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

YzSama

2017-03-07 14:46:46 +08:00

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

powerfj

2017-03-07 16:31:49 +08:00

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

jadetang

2017-03-07 16:39:49 +08:00

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

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

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

tabris17

2017-03-08 08:58:34 +08:00

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

Aksura

2017-03-08 21:11:05 +08:00

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

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

PoetAndPoem

2019-02-19 10:57:24 +08:00

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