如何创建/更新顺序/索引很重要的多对多关系？

Question

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

要求：

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

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

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

id	playlist_id	song_id	index
1	1	50	1
2	1	24	2
3	1	21	3
4	2	12	1

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

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

Answer 1

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

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

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

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

您不想要或不需要的是此表中的额外id。它只会妨碍真正的密钥，并且正如您所说，尝试改组顺序会让人头疼。也许您不知道任何表都可以有composite key。