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

不用 JOIN 和子查询，你用什么 SQL，KV 最适合你。

连 SQL 都不敢用，还能指望用好其他的数据库？

不是让开发人员学习掌握如何用好 SQL，而是野蛮不让用，这样的团队能成长？

楼上一堆说数据库不好扩展的，请问主从会了不？数据库里面有几亿数据了没？

搞程序的人云即云害死人。

出于微服务的考虑,join 查询的确不太允许,除非将来按业务拆分数据库,你能保证你 join 的所有表都会被分在同一个数据库中,要不还是理解下 DBA 的苦衷,我们就经历过一次服务拆分,真的很恶心,拆分完各业务独立数据库,独立升级部署都很方便.

曾经试过两张百万表不用 join，那个业务代码逻辑写多了很多

最终还是要看具体的业务逻辑吧，一句就否掉 join 是不对的

减轻了 DB parse 的压力，却带来了处理请求和数据传输的压力。
这个想法是怎么来的呢？

@syyy 处理请求可以水平扩展，DB 则不能

@syyy 或很难

看来 v2 大多数都没到分库分表的阶段。

提供一个额外的思路吧。（浅见，也没写过什么很大的这种在线系统
这种情况还是分场景讨论，如果只是普通的系统，记录条数比较小的情况下，那你该用用。但是当量起来了，就得从另外一个层面来考虑。

假设一直在用 join，不考虑存储，当量起来了，一些计算操作会开始膨胀，机器 cpu 会加得非常多，那怎么办，mysql 水平扩展还是垂直扩展，垂直扩展，上更好的机器，水平扩展，将 mysql 做成集群的。请求更大，集群变得更大？这两种都比较难受，垂直扩展的话，不可能有更大的机器让你不停的换，水平扩展的话，存储也水平，扩展，同时 mysql 这种是有状态的服务，运维压力更大了。

那有一个比较简单的方式，降低 mysql cpu 消耗，就是让 mysql 只做存储的事情（上面各位大佬说的当 kv ），业务计算逻辑放到后端来做，这样计算量起来，只用水平扩展后端服务就好了，挂在 lb 后面的服务随便扩容缩容。运维成本会小很多。当 mysql 还是不够的话，就开始上分库分表了。

可以拍着胸脯说，出了问题我担着。看看他给不给用

为了以后分表分库考虑？还是只是做决定的人看了网上的文章，一拍脑袋说的

我觉得是这样，如果你能自己想出理由说服领导（或者哪怕是说服网友），比如用的好处和坏处都有什么，那你就可以用。
如果你自己都不知道为什么不让你用，那么不让你用就是合理的。

@love 而且网络 IO 慢得多

合理啊，DB 压力要降到最低的

请教下楼上的大佬不用 join 怎么实现以下需求？用关系型数据库存文章，每篇文章包含多个标签（一对多），每篇文章包含多个作者（一对多），后台管理页面需要按作者和标签检索并分页。

你如果经历过 db 挂了导致的事故就理解 dba 的苦衷了，按照微服务的设计思想，确实不应该多表联查，但是这是建立在非常大数据量的前提下，像我公司，业务数据都快百亿了，这时候再关联表查，db 妥妥的挂

@dawniii 为什么不考虑用 nosql?如果你数据量小当我没说

推荐用 join 的确实都是小白

@yukiloh 可以

@magicnian 这种关联关系挺常见的，所以最终归宿都是 nosql ？

小白太多了，估计让小白写 join 也写不对吧。。。