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

2017-03-06 16:52:21 +08:00
 lh934275738
因为现在项目数据处理量比较巨大，他以前是程序员，我感觉他希望我写的功能，全部用 SQL 处理，他觉得 SQL 的速度是最快的，导入的时候有个数据校验，因为比较复杂，情况多，这种，我选择用 JAVA ，今天因为谈到这个逻辑，我说出来，他说，你怎么以前不说，现在才说，说我这个处理数据最起码 10 分钟（一定要我用 SQL 分出情况来，我的天，我得写多少个 UPDATE 进行情况分类），结果 18S 以内还是本地机，服务器应该 10S 左右。我现在很多业务逻辑都用 SQL 处理，我非常不喜欢这种处理方式。
求解 SQL 处理业务逻辑优于 JAVA 吗？我觉得不优于，但是我们这边的业务负责人总是认为我刚毕业，结果我们部门来了几个所谓 3 年-5 年的，真心的，改前端复杂的请求修改，都是我找到方法，后端关于框架的一些问题基本上都是我解决的，也不是什么很难的问题，但是我真心超级烦
连续走了 3 个技术负责人，其中 2 个都是和业务负责人有矛盾，当然 2 个技术经理也是有点技术不过关或者情商不够，所以根本没有技术负责人和他将技术，他总是按照他很多年以前的技术来认为 JAVA 很垃圾，速度慢， CPU 占用大之类的
11770 次点击
所在节点    程序员
44 条回复
forestyuan
2017-03-06 22:48:38 +08:00
@jsou 这个就太极端了，就算业务代码层面就要保证数据没问题，在数据库里多一层限制 /校验有何不可？
ncisoft
2017-03-06 23:18:33 +08:00
传统企业级应用和互联网应用是非常不同的技术处理路线，露珠对数据库很熟吗？达到 dba 水平没？别提 MySQL 这个垃圾，至少也得是 Oracle SQL server 这种企业级数据库
ivvei
2017-03-06 23:18:51 +08:00
@jsou 业务逻辑放外面也就分布式上占点优势，其他谈不上特别的好处，反而是开发人员自身背景和偏好的影响更大些。
ivvei
2017-03-06 23:22:43 +08:00
@zacard 那只是你们的开发手册。要说逻辑复杂，金融, 电信，这两个行业是 sql 使用的重灾区，难道属于业务逻辑简单的类型？
ncisoft
2017-03-06 23:26:08 +08:00
我以前帮一个项目优化性能，有一个小伙子是搜狐出来的，动辄就是我们在搜狐是如何如何做的，如何如何地快，分表分库缓存一堆巴拉巴拉。最后我帮忙设计的方案完全没用互联网企业那套，他那套方案连评审都过不去，无他，业务场景不同。 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
程序可以很容易知道操作是不是并发的，数据库我可不知道，万一锁表了那就堵塞了。
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
@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
四楼是对的
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 的维护成本 相比 代码来说应该会高

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/345357

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX