我们公司不让开发使用 join 包括 left join,不让用子查询，合理吗？

[hackingwu]

我们公司规范不让开发使用 join 包括 left join,也不让用子查询，原因是为了减轻 DB 的压力，这样就导致我们一个多表联合查询的业务就要拆分多条语句，导致无效的请求和数据传输。我们业务是微服务架构。 我觉得是很不合理的。减轻了 DB parse 的压力，却带来了处理请求和数据传输的压力。 大家觉得呢？是我错了吗？

[love]

不知道楼上这些人哪里听说的 join 伤性能，你分几次查来自己在组装和在数据库端装配好了回来性能没有大的区别

[ragnaroks]

我们公司只有一个限制,一次事务时间不能超过 1ms,其它随意,这种情况下基本不考虑任何数据库逻辑了,都是应用本身去实现

[yulitian888]

先不说规定本身是否正确，但是企图用规定解决性能问题的公司，一定是没有经历过性能问题的公司。
再说这个规定正确吗？嗯，很有可能你们没有一个合格的 DBA，或者，干脆就没有 DBA 吧？！
在这样的公司里，合不合理有意义吗？

[loveyu]

合理，回想 3 次拆表时的痛苦，以那几次的经验，99%的连表都是可以避免或去掉的。

[saberlong]

根据产品定位和场景。能用 join 的话，我更相信没人会故意不用，开发效率上相差太多。不单需要处理更多的计算逻辑，大概率面临性能，资源，开发成本的平衡问题。不是不得已，不会脑抽干这个事情。数据库服务器承载压力总会有上限，不管你是多高端的机器。千万级的表进行大量 join 和复杂的计算，优化到很短就能出结果很常见。不用多，可以尝试下几十几百个同时进行试试会是什么结果。读写分离只能有限改善。只有做分布式，分库分表才有无限扩展的可能。但是这种做法直接导致了很多时候无法 join 。所以很多做法是根据业务场景设计库表，比如将同个用户的数据归到同个分片中，这样只访问该用户数据时可以 join 。无法 join 的时候设计方案处理。放心，总会碰到的

[NotNil1]

今天就被这个问题搞的很烦，数据库查询 3s 超时，但是我一个统计的 sql，要 10s 左右，然后为了不超时，分批拉到内存里统计，10s 的 sql 在内存里要统计好几分钟。

[wangyzj]

这么一刀切
网络 IO 产生的时间不考虑？
而且我不相信会有人用更好的算法去解决数据库中已经固化的算法
过分的 join 或者笛卡尔积是有问题
但是不代表 join 没有优点啊
至于已经分的表，那没办法了，但是不能一刀切

[CoderGeek]

个人觉得一下几点
1.部分人员水平 有些写的 sql 性能底下 索引 优化不懂，减少这种问题禁止 join
2.没有专职 dba 像我们之前生成 sql 都要执行 sql 语句给 dba 审核的
3.分库分表 统计 没存储过程没视图 要么换 nosql 要么用冗余字段宽表减少 join es 一类的统计
4.前人留下脚手架 后续懒惰 成本不替换 比方说 java dao mapper，傻瓜式

[Felldeadbird]

我业务偏向内部系统为主，我很难想象不给用 JOIN，子查询。写财务功能业务代码得写多少逻辑，去组合数据。

[Vegetable]

一朝被蛇咬，十年不 join

[qbmiller]

我们业务上还真没有 Join 除了配置表

[neoblackcap]

@chamuyaye 游标分页，然后上搜索功能。那种传统分页在大数据情况下都是要禁掉的

[neoblackcap]

讲道理，这些人都是很机械地遵循某些规则。阿里的数据多大啊，它的系统想用 join 都用不了，很多表都分库分表了，显然 join 不了了。
另外一个例子就是谷歌，按照谷歌那边大牛的说法，你们在分布式系统里面用 SQL 就是弱者的表现，BigTable 这样的数据库才是正道。
所以不是什么合理不合理，要结合实际情况，因地制宜。我见过从上线到下线都没有超过 10 万数据量的系统。这样的系统我用不用 join 有关系嘛？哪怕不上索引都没有太大关系。
问合不合理之前先看看数据量有多少，系统的客观限制是什么，有没有时效性的限制，是不是分布式系统。仅仅上来就问合不合理，其实你这更多是发泄情绪，寻求认同，我觉得可以理解，但是这对你没有帮助。你应该多点了解你们的系统，多做实验，然后拿数据说话。这样哪怕是领导错了，但是他们不改，你下一份工作你也懂得什么规范是好的，什么规范是画蛇添足。
好比马克斯主义是好，列宁主义是好。但是不本土化，能救中国吗？

[rogwan]

完全禁止 join 矫枉过正了，不超过 2 张表 join 没什么问题。

[Cielsky]

面向领导编程
面向 money 编程
这样你就没有烦恼了

[chihiro2014]

合理，其实说不定请给专业的 DBMS 开发人员更为合理？

[coldear]

禁止 join 可以理解，其实应该使用非关系型数据库

[xy90321]

@love

left join 优化的不好还真的可能会比自己在应用层拼装慢得多

随便几张百万数据级别的表全表扫描一下再来个笛卡尔积谁受的了？

SQL 只是降低了实现的门槛，但不意味着肯定高效，或者说，不意味着在相同付出下一定更高效

[lihongming]

nosql +1

先分析一下你们的真实需求吧，就绝大多数公司而言，90%的请求都是单表甚至单条，用关系型数据库仅仅是为了那 10%的请求。

亚马逊就是意识到了这一点，才开发了 dynamodb，现在这个数据库是 aws 最最主推的产品。

[yukiloh]

顺便问下,jpa 可以做到十张表联查吗
我上次查 3 张表(一对一对多)就报错了