一张主表，多张关联表，查询逻辑写在 sql 中好，还是业务代码中好？

[shadow1949]

例如现在有表 a ，和多张关联表 a1,a2,a3……然后之间关系可能是 1:1,1:n,n:n 。 这种情况要查询 List<A>，然后 A 里面有多个关联表的对象，这种情况大家一般直接写在 mapper 中多表关联，还是写在业务代码中？

个人以为： sql 中：只查一次，不用匹配字段，组装；但是不好维护； 业务代码中：逻辑清晰，便于维护；但是不好组装

大家怎么看这个问题……

[andytao]

这得看使用的框架是哪种，然后才能评估哪种维护成本更低、操控性更强。比如 Laravel 对连接支持很好，写在代码里没毛病。

[hhjswf]

为啥不好维护？代码中好维护在哪

[freeup]

我个人能通过 sql 一次性查出来的 肯定就写 sql 了 简单方便 一个查询就能把需要的查出来 而且分页 条件查询 排序 都比较的方便

[brezp]

我觉得业务代码中写好，封装的方法也能有效提高后续的开发效率；
sql 里面 join 的查询很难写到业务通用，一般都是一个查询 sql 一个复杂 join 查询吧，难维护而且很难复用

[e7]

join 一般最多 2 、3 张表，建议拆一下，查 2 次吧，剩下的数据整理写在业务中

[aababc]

感觉这个事情是针对场景的，如果是后端的复杂的筛选，排序写在 SQL 里可能有方便处理，但是连表的数量过多也是一个大问题。如果是针对单个数据的处理(1 -> N -> N) 可预见的小批量数据，感觉写在业务里更能方便数据的组装和业务的变更。

[xppppsfg]

记得一个月前 v2 有个帖子有个老哥吐槽同事全写在 sql 里,下面吵起来了

[BeautifulSoap]

代码里把逻辑拆开来必定需要先获取关联 id ，然后 where in (1,2,3,xx) ，所以我觉得问题在于 where in 的性能，只要 where in 性能没问题那代码里拆开来我觉得更好

[Chad0000]

一律写在业务中，这样方便缓存。比如你另外一张表是客户表，高度访问已经缓存起来了。

[onhao]

看结果， 过程最优，都是建立在看客自己的经验立场上的。一定要说那个好，还是很多老哥说的分场景。
看了大部分人都建议你放到程序中处理，我偏偏建议你还是放 SQL 里，
放 sql 简单，阅读简易。
放代码中，估计看代码都挺费劲了
简易简洁高效的代码比较好。

[aragakiyuii]

1 楼+1
主要看你用的什么框架，框架不支持我觉得还是写到 SQL 里，除非说你代码写的挺漂亮

[dayeye2006199]

OP 得描述一下你的业务是什么，数据大概有多少，否则也不好推荐解决方案啊。

比如你这应用是个 2b 的 erp ，那肯定是直接放 SQL 就可以了，不容易出错，数据库性能也好。

如果你是 2c 需要大量 qps 的，数据库会变成瓶颈的，那可能考虑拉到服务端处理合理一些。

但总体来说，只要数据库不是瓶颈，一律推荐 SQL ，数据库在表设计合理的情况下，做这样的工作性能比自己撸的代码强的多。

[THESDZ]

如果团队的水平比较高,建议拆分后放在业务里面,然后信任封装的方法,给人所见即所得的代码命名风格(或者框架支持)

否则就 sql 一把梭好了...

[ToBeHacker]

数据库难以水平伸缩，现在的趋势都是把业务堆到应用里。

[jessun1990]

如果两者没有明显优势的话，倾向于 sql 。原因是
1. 防止框架出现 bug ；（较少场景）
2. 以后迁移框架方便。（极少场景）

[RainCats]

只要不是作为过滤条件的关联表我都选择在代码里写多一个查询来拼接数据

[darksword21]

快槽猛就 sql 不然就

[weizhen199]

如果真的是很多张，我还是建议你考虑下你 DB 的 tmp 空间。
挺容易爆炸的。

[zergzq]

建议写代码 不写 SQL 。级联查询对数据库来说 随着数据增长有很大的风险。

[gam2046]

个人是一律丢数据库，毕竟写起来简单，后期数据库顶不住还可以读写分离、一主多从。有的小伙伴自己实现的 left join 逻辑真的感人，一言不合就笛卡尔乘积。

都丢数据库，至少下限是比较高的。哪怕是初学者也不会写的太垃圾。