替代多个LEFT JOIN的巨大结果集

Question

我正在寻求一些关于处理LEFT JOIN多个表时结果集中的行数会爆炸的情况的建议。我理解这是预期的行为，但我想知道处理它的推荐方法。我知道我可以让我的应用程序执行多个查询以减少整体返回的行数，但我试图看看是否有办法让SQL完成大部分繁重工作但仍然只进行一次“往返”（例如，la this answer）。

实施例

这是我的SQL：

SELECT al.title albumTitle
    , releaseDate
    , name artistName
    , duration
    , t.title trackTitle
    , styleName
FROM album al
LEFT JOIN lu_albumartist aa ON aa.albumId = al.albumId
LEFT JOIN artist ar ON ar.artistId = aa.artistId
LEFT JOIN track t ON t.albumId = al.albumId
LEFT JOIN lu_albumstyle ast ON ast.albumId = al.albumId
LEFT JOIN style s ON s.styleId = ast.styleId
WHERE al.title LIKE '%A Love Supreme%'

此SQL Fiddle有助于证明问题：

我正在检索有关音乐专辑的信息。 我真的只需要11行才能让我的应用程序填充所有字段（1个专辑，4个艺术家，3个曲目，3个样式），但查询会回退36行。我将无法使用大多数行;例如，我并不关心风格和风格的所有排列。艺术家或风格＆amp;轨道。当我为其他东西添加更多LEFT JOINS（例如乐器，格式，评论，曲目播放信息等）时，排列的数量可以扩展到10,000s！

理想情况下，我想要的是一个更简洁的结果集：

超级精简：4行（以这种方式读取表没有多大意义，尽管应用程序可以解析它）

|          title |                releaseDate |           name |    duration |                                  title |   styleName |
|----------------|----------------------------|----------------|-------------|----------------------------------------|-------------|
| A Love Supreme |                       1965 |  John Coltrane |         479 |               Part I - Acknowledgement |   Free Jazz |
|    [something] |                [something] |    McCoy Tyner |         435 |                   Part II - Resolution |    Hard Bop |
|    [something] |                [something] | Jimmy Garrison |        1060 | Part III - Pursuance / Part IV - Psalm |       Modal |
|    [something] |                [something] |    Elvin Jones | [something] |                            [something] | [something] |

......“[某事]”只是意味着价值可以是任何东西;该应用程序不会关心

紧凑：11行（对人类有意义）

|          title |                releaseDate |           name | duration |                                  title | styleName |
|----------------|----------------------------|----------------|----------|----------------------------------------|-----------|
| A Love Supreme |                       1965 |                |          |                                        |           |
|                |                            |  John Coltrane |          |                                        |           |
|                |                            |    McCoy Tyner |          |                                        |           |
|                |                            | Jimmy Garrison |          |                                        |           |
|                |                            |    Elvin Jones |          |                                        |           |
|                |                            |                |      479 |               Part I - Acknowledgement |           |
|                |                            |                |      435 |                   Part II - Resolution |           |
|                |                            |                |     1060 | Part III - Pursuance / Part IV - Psalm |           |
|                |                            |                |          |                                        | Free Jazz |
|                |                            |                |          |                                        | Hard Bop  |
|                |                            |                |          |                                        |     Modal |

我不太关心性能而不是我的应用程序的代码可移植性，可读性和＆amp;可扩展性。

根据earlier linked question，其他答案和评论建议我不应尝试加入超过3个表格。

1. 我应该放弃这种方法吗？如果我要使用多个查询，可能会有十几个或更多。
2. 我怀疑UNION ALLs有办法解决这个问题，但这是最好的做法吗？
3. 我猜这是一个相对常见的问题，但我无法找到一个好的答案或一套指导方针。这种情况的推荐方法是什么？

Answer 1

我可以告诉你如何以第一种方式做到这一点。

我会使用多个查询，但不是每个查询一个查询，而是查询多个相关内容。就像你在查询中已经做过的那样。但我可能会删除曲目并使用此查询进行专辑搜索（例如discogs以及其他提到的网站）。

如果用户随后选择了一个相册，我会在一个查询中加载多个其他相关内容。喜欢在一个查询中使用曲目播放信息的曲目，在另一个查询格式和乐器等中。所以我会把相关的东西放在一起，实际上就像我会把它放在ui上一样。

与往常一样，我会尽量保持简单。并考虑用户在一个页面上需要多少信息。如果用户主动想要看到它，有些东西可以加载延迟。

我认为不要加入超过3个表的建议。考虑一对一或多对一关系，其中最多返回一条记录，记录数量不会变大。