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

[hackingwu]

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

[liuxey]

1. 看业务类型
2. 看谁职位大
3. 出问题谁背锅

[ychost]

离线计算的话，无所谓的

[howellz]

这还用啥 SQL 啊，SQL 的作用不就是在 db 层面帮你把这些优化做好么?自己在 Client 端写代码去优化整理？把数据库当空气？

[sanggao]

我可以正经告诉你，严格禁止 sql 联表查询，review 发现了你赶紧改去！

[mandex]

具体问题具体对待，有没有性能问题可以测试，为啥要全部禁用呢。
很多地方明明没有性能问题，不让用 JOIN 导致增加了工作量，并没有意义吧。

[changdy]

233 楼上说合理的....让人看不懂, 只能说这个由业务决定和系统架构决定
传统 erp join7~8 张表..再常见不过了...
如果系统的边界划分的非常清晰 , 业务方对查询的要求比较低 当然 join 尽量少....

[newtype0092]

关系型数据库禁止通过关系关联查询？我《数据库系统概论》白学了。。。

[optional]

合理。 互联网 otap 应用不应该用 join.
理由：缓存友好，方便 sharding，方便优化拆分。

[optional]

@newtype0092 其实数据库范式之类的都是面向传统软件的。
大流量的互联网应用都是拿数据库都 kv 用的。

[opengps]

如果你将来数据库达到跨 2 台以上机器，你立刻会改口说很合理！
这种规定说明制定规则的人出发点有分库思路，当然业务是否能达到用的上分库则是另一个话题

[wangsd]

现在公司搞 MES 的，join 十几张表都见过。

[palfortime]

我认为在大部分开发写代码都是复制 /粘贴模式，与实时系统有连接的数据库上都应该禁止 join 。业务做大后，这些语句都已经扩散到整个系统了，大部分领导没有这个魄力来改。

像我司 sql 一把梭，开发时那个爽，也不评估需求是否合理，反正一条 sql 可以处理。db 性能不够？买台核数更大的。
结果，我们的系统被客户采购部署过去时，Oracle 被要求换成 MySQL，核数也有上限。量上来之后，三五天一个炸，都不忍心看客户群里的消息。

[hiboshi]

非常合理 尤其是互联网业务

[bsg1992]

@optional 那你为什么不直接用 KV 用啥关系数据库呢？
你如何判断出一个应用在开发之前是大流量应用呢？

[starcraft]

哈哈哈 刷新认识。第一次见能把懒得学数据库优化 说的这么高大上。你们这帮人不当领导真是可惜了，做个螺丝钉写 crud 真是糟蹋你们。

[yxjn]

有的需求不用 join 根本做不了啊，比如说两个表联合查询，查询条件分布在两个表里。
或者按照题主说的分两步走。如果一个表 in 另一张表的数据，而另一张表查出来的数据又非常多。很容易造成 sql 过长，mysql 甚至执行不了，或者效率严重降低。
既然选择了关系型数据库，就要明白为什么选择它。

[BigBrother1024]

从不关系这类问题，有问题直接向公司提呀

[whoami9894]

那干脆别用关系数据库，不让跨表查询，换 NoSQL 存冗余数据

[optional]

@bsg1992 kv 确实很多啊，但是关系型数据库成熟的索引，读写分离之类的都很方便。只不过用 1+N 查询代替了 jion，但是后台管理，数据分析等 olap 还是大量用 join 的。

[syasuker]

OLTP OLAP 自己看