这是一个创建于 3149 天前的主题，其中的信息可能已经有所发展或是发生改变。
因为现在项目数据处理量比较巨大，他以前是程序员，我感觉他希望我写的功能，全部用 SQL 处理，他觉得 SQL 的速度是最快的，导入的时候有个数据校验，因为比较复杂，情况多，这种，我选择用 JAVA ，今天因为谈到这个逻辑，我说出来，他说，你怎么以前不说，现在才说，说我这个处理数据最起码 10 分钟（一定要我用 SQL 分出情况来，我的天，我得写多少个 UPDATE 进行情况分类），结果 18S 以内还是本地机，服务器应该 10S 左右。我现在很多业务逻辑都用 SQL 处理，我非常不喜欢这种处理方式。
求解 SQL 处理业务逻辑优于 JAVA 吗？我觉得不优于，但是我们这边的业务负责人总是认为我刚毕业，结果我们部门来了几个所谓 3 年-5 年的，真心的，改前端复杂的请求修改，都是我找到方法，后端关于框架的一些问题基本上都是我解决的，也不是什么很难的问题，但是我真心超级烦
连续走了 3 个技术负责人，其中 2 个都是和业务负责人有矛盾，当然 2 个技术经理也是有点技术不过关或者情商不够，所以根本没有技术负责人和他将技术，他总是按照他很多年以前的技术来认为 JAVA 很垃圾，速度慢， CPU 占用大之类的
求解 SQL 处理业务逻辑优于 JAVA 吗？我觉得不优于，但是我们这边的业务负责人总是认为我刚毕业，结果我们部门来了几个所谓 3 年-5 年的，真心的，改前端复杂的请求修改，都是我找到方法，后端关于框架的一些问题基本上都是我解决的，也不是什么很难的问题，但是我真心超级烦
连续走了 3 个技术负责人，其中 2 个都是和业务负责人有矛盾，当然 2 个技术经理也是有点技术不过关或者情商不够，所以根本没有技术负责人和他将技术，他总是按照他很多年以前的技术来认为 JAVA 很垃圾，速度慢， CPU 占用大之类的
 | 1 Sharuru 2017-03-06 16:55:07 +08:00 连续走了 3 个技术负责人，其中 2 个都是和业务负责人有矛盾，当然 2 个技术经理也是有点技术不过关或者情商不够 推荐楼主把 3 个变成 4 个。 |
 | 2 lh934275738 OP @Sharuru 没有技术负责人了，因为我们属于乙方，类似于外包，但是比外包好一丢丢，走了一个之后，后面连续跪了 2 个技术负责人，直接就不招技术负责人了。因为公司部门合并，本来借调，结果变成转部门了，待遇相对来说会好一点，但是我是一定要走了，我真心受不了这个业务负责人了，一直在找工作，想找那种可以安心做 2 年以上的那种标准找的，结果发现根本没有面试，发面试邀请的基本上我都不想去，蓝瘦，现在只想换家互联网公司了，今年投了这么多简历，好不容易有一份面试，降工资就降了，后悔当时的表现了。 |
 | 3 F281M6Dh8DXpD1g2 2017-03-06 17:24:39 +08:00 标准答案不是看业务场景么 |
 | 4 zacard 2017-03-06 17:34:36 +08:00  1 恰恰相反。 sql 中尽量少的逻辑，甚至有时候一个 join 都需要拆到 java 中先业务处理，然后写成 2 条简单 sql 处理。 原因如下： 1.业务逻辑都在 sql 中，数据库将成为瓶颈。且数据库做分布式集群是比较困难的。而业务系统就相对更容易做分布式集群处理。 2.简单多条 SQL 的效率可能远大于一条连表查询 SQL ，详见 MySQL 权威指南等书籍。 3.业务逻辑在 java 中，能够保持扩展性、容错性等等，而 sql 中，连迁移数据库都是件头疼的事情，更别提扩展了。 。。。等等 |
 | 5 shoaly 2017-03-06 17:38:02 +08:00 越复杂的逻辑越应该从 sql 里面剥离出来, 放到代码里面 先不说效率问题, sql 长代码一时爽 日后维护的成本太高了 |
 | 6 ivvei 2017-03-06 17:42:00 +08:00 这东西得看，不能一概而论。跟业务，跟数据库本身，都有一些关系。 |
 | 7 linfeng123 2017-03-06 17:43:58 +08:00 fsadf |
| 8 lh934275738 OP @shoaly 维护真心要爆炸，还好现在又简了需求，之前因为加了个需求并且是需要分组的，结果有一个很小的一个方面没考虑到，炸了 |
| 9 lh934275738 OP |
 | 10 Finest 2017-03-06 18:24:58 +08:00 到时候天天整理慢查询 SQL 就蛋疼 |
| 11 zacard 2017-03-06 19:49:19 +08:00 @lh934275738 项目小，不复杂，你写那里都无所谓。 我们这个是入开发手册的， sql 运算、逻辑都不允许。简单逻辑你直接 mybatis 里处理，别放 sql 里啊。 sql 里不能有逻辑，我觉得应该不论什么情况都是正确的！ |
 | 12 aheadlead 2017-03-06 19:56:27 +08:00 从某种角度说， CPU 能跑满也算是个好事，毕竟没卡在 IO 上… |
 | 13 huiyue 2017-03-06 20:40:10 +08:00 如果业务逻辑简单，且在可以预见的几年内不会出现性能上的担忧， SQL ，存储过程写多复杂都无所谓的。 如果可以预见未来需要分布式，需要对性能进行考量，需要对业务逻辑进行平凡修整，还是在代码里面比较好。 |
 | 14 weizhiyao008 2017-03-06 21:08:58 +08:00 高计算量的放 JAVA 里面挺好啊，高 IO 的放 SQL 也不错。。。看情况吧 |
 | 15 Infernalzero 2017-03-06 21:52:26 +08:00 4 楼已经把能说的都说了， LZ 你看着办吧 |
 | 16 0915240 2017-03-06 22:08:02 +08:00 我们这边也不允许 SQL 中有逻辑。包括存储过程、触发器等。 |
 | 17 jybox 2017-03-06 22:20:22 +08:00 - 如果是对数据的约束，更适合放到 SQL （保证最终的数据符合约束） - 如果逻辑复杂到难以用 SQL 表达，更适合放到应用（毕竟 SQL 表达能力不如通用语言强） - 如果是 IO 密集，且必不可少的工作，更适合放到 SQL （减少传输量和对数据的反复扫描，但前提是这个工作「必不可少」，不能因为放到 SQL 中来做而增加无意义的工作） - 如果是计算密集，更适合放到应用（应用更容易进行横向拓展） |
 | 18 yangqi 2017-03-06 22:21:39 +08:00 sql 能处理的一些简单逻辑肯定是比查询完出来处理效率要高的，不过具体的肯定要看场景来定的 不够确定就是 sql 的里面的逻辑不容易测试和调试，所以不用也没有问题，具体还是要看情况。 |
 | 20 jsou 2017-03-06 22:39:10 +08:00 业务逻辑一定要尽可能不往 sql 里放。 调试，兼容，分布式，可维护性，扩展性... 我觉得在这一点上不存在“分情况看待”的必要。 现在对数据库使用的主流方向是只用来存储数据，越来越多的项目都强制规定对于像存储过程、定时器、触发器都不允许使用。甚至外键都不允许使用。 如果要问为什么不用，请先问为什么要用，数据合理性在业务代码层面就要得到保证。 |
 | 21 forestyuan 2017-03-06 22:48:38 +08:00 @jsou 这个就太极端了，就算业务代码层面就要保证数据没问题，在数据库里多一层限制 /校验有何不可？ |
 | 22 ncisoft 2017-03-06 23:18:33 +08:00 via Android 1 传统企业级应用和互联网应用是非常不同的技术处理路线，露珠对数据库很熟吗？达到 dba 水平没？别提 MySQL 这个垃圾，至少也得是 Oracle SQL server 这种企业级数据库 |
| 23 ivvei 2017-03-06 23:18:51 +08:00 via Android @jsou 业务逻辑放外面也就分布式上占点优势，其他谈不上特别的好处，反而是开发人员自身背景和偏好的影响更大些。 |
| 24 ivvei 2017-03-06 23:22:43 +08:00 via Android @zacard 那只是你们的开发手册。要说逻辑复杂，金融, 电信，这两个行业是 sql 使用的重灾区，难道属于业务逻辑简单的类型？ |
| 25 ncisoft 2017-03-06 23:26:08 +08:00 via Android 我以前帮一个项目优化性能，有一个小伙子是搜狐出来的，动辄就是我们在搜狐是如何如何做的，如何如何地快，分表分库缓存一堆巴拉巴拉。最后我帮忙设计的方案完全没用互联网企业那套，他那套方案连评审都过不去，无他，业务场景不同。 MySQL 这么垃圾的数据库也就互联网企业敢用 |
 | 27 ericls 2017-03-06 23:36:32 +08:00 做 benchmark 看看？ |
 | 28 akira 2017-03-07 00:23:19 +08:00 |
 | 29 loading 2017-03-07 06:52:56 +08:00 via Android 程序可以很容易知道操作是不是并发的，数据库我可不知道，万一锁表了那就堵塞了。 |
 | 30 linbiaye 2017-03-07 09:33:56 +08:00 懒，不想自己做。 |
 | 31 sun1991 2017-03-07 09:46:52 +08:00 对传统企业级业务逻辑来说：十几年后 SQL 还是那个 SQL ， Java 或许面目全非了（语言，框架， IDE 工具等等）。不过 SQL 写逻辑一坨一坨垃圾一样的代码，复杂点的更是写的想死。 Java comes and goes, but SQL stays forever ;) |
| 32 zacard 2017-03-07 10:20:16 +08:00 via iPhone @ivvei 重灾区并不能说明其是合理的。银行与电信重度依赖 sql 更多的是因为早期系统更多的依赖动辄百万性能强劲的小型机和 oracle 数据库，这在当时的性能确实比 java 虚拟机中的程序来的快。 |
 | 33 suikatw 2017-03-07 10:54:11 +08:00 我司也是重代码逻辑，轻 sql 逻辑 真的需要性能的情况下都是直接打 mysql 的 patch ，特定场景专门优化 看到有同学提到了存储过程，我想了解下存储过程的版本管理是怎么做的，以及存储过程的版本管理怎么与代码的版本管理结合 |
| 34 ivvei 2017-03-07 11:04:00 +08:00 @suikatw 存储过程也是代码，代码怎么做版本管理，存储过程就怎么做管理。把存储过程弄到生产数据库里编译，那是代码发布的阶段了。 |
 | 35 dexterzzz 2017-03-07 11:26:57 +08:00 1 请用上企业版的 orcale ， sql server 了再来说数据库性能，功能。 |
 | 36 xiaochong 2017-03-07 12:21:22 +08:00 via iPhone 四楼是对的 |
 | 37 killerv 2017-03-07 13:37:24 +08:00 sql 中最好不要涉及业务逻辑，看场景，能拆就拆， join 、子查询的效率并不高，甚至有时候低的夸张 |
 | 38 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 是这么干，并不意味着几十年过去后还要这么干。 |
 | 39 YzSama 2017-03-07 14:46:46 +08:00 SQL 和 Java 的市场需求不同。 看市场，使用 SQL 会比 Java 多？ 在 SQL 里面写了一堆逻辑，这不明显增加维护成本？ 明明可以招个写 Java 的进来写业务代码就好了，现在偏偏要招 SQL 人员来写。 后者需求少，价格明显也比 Java 高。 |
 | 40 powerfj 2017-03-07 16:31:49 +08:00 sql 的维护成本 相比 代码来说应该会高 |
 | 41 jadetang 2017-03-07 16:39:49 +08:00 这个看需求的，一般来说，互联网项目会依赖数据库比较少，很多业务逻辑都在应用层面做了。但是传统企业的项目，技术架构就没有那么先进，采用的多数是， Transaction Script https://www.martinfowler.com/eaaCatalog/transactionScript.html 这种模式扩展性会比较差，但是有一个前提是你的业务量达到了需要扩展的那个点。 |
 | 42 tabris17 2017-03-08 08:58:34 +08:00 这个问题可以简化为：《业务负责人是傻逼怎么办？》 |
 | 43 Aksura 2017-03-08 21:11:05 +08:00 2 看你需求的类型， OLTP 的业务逻辑只要不涉及事务的，尽量在程序里维护； OLAP 的业务逻辑你不用 SQL ，数据正确性、一致性这些你自己程序维护，时间稍长都是坑。 数据库性能这个，如果只用过 MySQL ，真的就不要提了。 |
 | 44 PoetAndPoem 2019-02-19 10:57:24 +08:00 @Aksura 感谢。不过很疑惑什么样的软件可以被称为 OLAP，涉及到数据分析模块的软件吗？ |
Select Language