对于这个问题，我建议你在不考虑其他优化层面的情况下，将拼装数据的压力放在代码层面，也就是在服务器端处理。理由如下：
数据库层面的查询和连接操作可能会引发额外的IO负载，可能会在数据量较大时导致性能下降。而在服务器端使用代码循环拼装数据，可以在内存中高效操作，减少IO负载。
循环拼装数据可能会导致性能损耗，但在你给出的情况下，主表50条，两张链接表一共20条，循环拼装100次，这个量级应该是可以接受的。而且，现代服务器一般都具备较好的计算能力，可以快速处理这种数量级的操作。...
建议跑下数据，看看这 100 次循环操作大致的耗时。理论上这个量级的循环基本花不了几 ms，放后台处理就行了。但具体得看你这里业务上后续有无扩展性需求，查询的时延要求等等。简单来说就是往后看两步，不至于两个月后又要改动这个方案。
你用 for 循环嵌套拼接数据实际上也是把压力放到数据库层了，其次每次跟数据库交互要创建连接，这个创建连接可能比查询还耗时，所以最好的操作应该是尽量减少连接的创建，也就是你说的写多表联查的sql会比较合理，另外问一句：用 for 循环查数据，给你做code review的人不会给你打回去吗[疑问]
不过数据量不大的话，其实怎么做都是合理的，基本没啥感知，所以还是看你想怎么写了[咖啡]，不过最好还是养成不在 for 循环里查数据的习惯
对于这个问题，我建议你在不考虑其他优化层面的情况下，将拼装数据的压力放在代码层面，也就是在服务器端处理。理由如下：
数据库层面的查询和连接操作可能会引发额外的IO负载，可能会在数据量较大时导致性能下降。而在服务器端使用代码循环拼装数据，可以在内存中高效操作，减少IO负载。
循环拼装数据可能会导致性能损耗，但在你给出的情况下，主表50条，两张链接表一共20条，循环拼装100次，这个量级应该是可以接受的。而且，现代服务器一般都具备较好的计算能力，可以快速处理这种数量级的操作。...
建议跑下数据，看看这 100 次循环操作大致的耗时。理论上这个量级的循环基本花不了几 ms，放后台处理就行了。但具体得看你这里业务上后续有无扩展性需求，查询的时延要求等等。简单来说就是往后看两步，不至于两个月后又要改动这个方案。
你用 for 循环嵌套拼接数据实际上也是把压力放到数据库层了，其次每次跟数据库交互要创建连接，这个创建连接可能比查询还耗时，所以最好的操作应该是尽量减少连接的创建，也就是你说的写多表联查的sql会比较合理，另外问一句：用 for 循环查数据，给你做code review的人不会给你打回去吗[疑问]
不过数据量不大的话，其实怎么做都是合理的，基本没啥感知，所以还是看你想怎么写了[咖啡]，不过最好还是养成不在 for 循环里查数据的习惯