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

[hackingwu]

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

[Mithril]

@PhpBestRubbish 传统以数据库为核心的开发确实是这样的。但是现在数据量上来不会炸的吗？

[Kairyuu]

我们业务里面不让用 统计的功能可以但是也让少用

[dog82]

你们公司只是把数据库当黑盒子使用，没 DBA 吧……
说白了就是守着金山挖煤
充分理解并合理使用各种数据库特性是一个健康的开发团队必须具备的

合理使用数据库特性达到业务目的，比自己 code 强壮得多

[janwarlen]

合理，但是有前提。
前提是表设计合理，如果在辣鸡表设计的基础上这么要求，就相当于让你用竹篮子打水

[nnd]

合理个锤子，领导无能累死士兵。不让用的本质原因是领导自己能力太菜，担心员工能力也菜，用不好，反而拖累数据库。就像现在很多城市禁摩，并不是摩托车污染环境，本质就是管不好，懒政。任何技术都要使用在合适的场景，合理的使用。

阿里的规范是禁止使用存储过程，不是禁止使用 join 。

禁止使用 join，是否能够提高效率，减轻数据库的压力？
答案基本是否定的：
1. 试问各位那个有信心能够写出数据库查询引擎，写出的代码效率比 SQL 引擎效率更高？
2. 不使用 join 和业务实现没有关系，业务实现还不是要从数据库拉取数据，难道这个步骤不增加数据库压力？
3. 完全禁止 join，不如使用 NoSQL 数据库。关系性数据库合理使用就包括使用 join 。
4. 如果感觉业务开发写不好 SQL, 不如增加 DBA HC，做 SQL 审计，效率和质量都比不适用 join 好，并且能节省开发时间。

[monkeyWie]

看业务啊，如果以后数据会很大要分表分库就合理，否则就是搞自己

[chamuyaye]

想问下如果不使用，但是又有分页的要求（数据在各个表中）这种怎么办

[chendy]

除非能把业务逻辑，代码逻辑和数据库设计都优化到不用 join，否则就是在搞自己…

[dog82]

@nnd 不让用存储过程可以理解，因为可移植性太差了

[ranxy]

业务很容易扩展，加机器就行，而数据库不能这么简单的解决。

[AngryPanda]

@huijiewei 微服务和 JOIN 有啥必然联系吗

[smilenceX]

看情况。
这个问题涉及到数据量，索引，查询计划等等各种因素。特别是在多个表联查的时候 join 有时不能正确使用合适的索引导致查询变慢；此外，如果设计不合理，在与其它数据库操作并发时，增加死锁的可能性。
技术之外，如果公司没有专职的 DBA，考虑到开发人员的数据库水平不一致，为避免出现这些问题，硬性做出这种一刀切规定倒也不是不能理解。
确实如你所说，会导致不必要的数据传输，但综合下来，也许是一个可以接受的代价。
为什么会有无效的请求呢？这一点没有理解。

[akira]

小公司随便你搞。

[BBCCBB]

完全禁止不合理.

能少用就少用时合理的..

[asAnotherJack]

@chamuyaye #27 我也想问这个问题

[nnd]

@dog82 不但一致性查，开发写的存储过程也是惨不忍睹。开发写 SQL，就像汽车司机骑自行车；写存储过程是写独轮车，翻车不可避免。当然数据库引擎层面，SQL 引擎效率通常高于 PL/SQL; 我在 O 上面测试过同样的 SQL 、PLSQL，SQL 性能最大好 50 倍

[inwar]

合理,你不一定写得好联表 sql

[ferock]

估计你是 java

各种 Dao，各种 Do，各种单库单对象的权限限制。
当然不能 join，否则还要单独写返回值的对象。

其实完全可以充分利用内存嘛

[dominic0312]

非常合理,,,,,,,,,

[mmdsun]

50%合理

1~2 张表连是可以的。多了不行。

单表可以多线程分多次查，加冗余字段。或者数据聚合导入 es，数据仓库查询。