-1

假设您正在创建一个音乐应用程序。您有一张播放列表表和一张歌曲表。您将如何在 SQL 环境中为播放列表中的歌曲顺序关系建模？

要求：

  • 每个播放列表可以有多首歌曲
  • 播放列表中的歌曲顺序很重要
  • 每首歌都有自己丰富的信息（艺人、专辑等）

在客户端，这很简单，只需要在播放列表上有一系列产品 ID，然后从中获取歌曲信息。如果顺序发生变化，只需更新数组并推送一个新数组。计算密集但很容易推理并且没有双倍索引条目的机会。

在关系数据库世界中，通常对于多对多关系，您会使用联结表。其中每个 playlist_id 对应一个 song_id。您可以为索引添加一列，但是当您更新播放列表的顺序时，您必须重写所有索引的顺序。

ID playlist_id 歌曲编号 指数
1 1 50 1
2 1 24 2
3 1 21 3
4 2 12 1

我正在努力寻找这个问题的答案。

对于我的具体情况，我目前正在使用 Supabase 和他们的 Javascript SDK，它引用了一个托管的 PostgreSQL 数据库，一切都是从一个带有查询的客户端应用程序完成的。我不知道如何编写一个处理这个问题的 SQL 函数。与每次只推送一个新数组相比，这一切似乎都非常复杂，即使这是“正确”的方式。看起来 PostgreSQL 还不支持外键数组，那么有更好的方法吗？

4

1 回答 1

0

在关系数据库世界中，通常对于多对多关系，您会使用联结表。

是的，该联结表将是“所有键”——在这种情况下，它的模式将是它的键{playlist_id, song_id}。

大概（你不会这么说）一首歌可以出现在许多播放列表中，并且每个播放列表中的顺序不同。此外，您无法index从任何其他表中推断。 index只放在这张桌子上。此外（我猜）用户可能会通过随机播放同一组歌曲来重新排序他们的播放列表。

添加index意味着您不再拥有联结表。但是您仍然有一个表（其中一个），其键是{playlist_id, song_id}. 可能有一个替代键{playlist_id, index}，或者如果用户无意中将两首歌曲随机播放到播放列表上的同一位置，这可能是允许的，您将使用它song_id来解决平局。（这就是我要做的，以保持简单。在制造步骤中，这就像说我需要 4 个螺栓和 2 个夹子，但无论您按什么顺序安装它们都没有关系。）

您不想要或不需要的是id此表中的附加内容。它只会妨碍真正的密钥，并且正如您所说，尝试改组订单会让人头疼。也许您不知道任何表都可以有一个复合键。

于 2021-09-16T22:33:00.303 回答