3
如何在关系数据库中存储订购的信息
我正在尝试了解如何在关系数据库中正确存储有序信息。 一个例子： 假设我有一个由歌曲组成的播放列表。在我的关系数据库中，我有一个的表Playlists，其中包含一些元数据（名称，创建者等）。我还有一个名为的表Songs，其中包含playlist_id和特定于歌曲的信息（名称，艺术家，时长等）。 默认情况下，将新歌曲添加到播放列表时，它将添加到末尾。按Song-ID（升序）订购时，该顺序将为添加顺序。但是，如果用户应该能够对播放列表中的歌曲重新排序，该怎么办？ 我提出了一些想法，每个想法都有其优点和缺点： 称为的列order，它是整数。移动歌曲时，所有歌曲在其旧位置和新位置之间的顺序都会更改，以反映更改。这样做的缺点是，每次移动歌曲时都需要进行很多查询，并且移动算法不像其他选项那样琐碎。 称为的列order，它是一个十进制（NUMERIC）。移动歌曲时，会为其分配两个相邻数字之间的浮点值。缺点：十进制字段会占用更多空间，并且可能会精度不够，除非在每次更改后都注意重新分配范围。 另一种方法是使用previous和next字段引用其他歌曲。（或者，如果现在是播放列表中的第一首和最后一首歌曲，则为NULL；基本上，您将创建一个链表）。缺点：诸如“在列表中找到第X首歌曲”之类的查询不再是固定时间，而是线性时间。 在实践中最常使用以下哪个程序？在大中型数据库上，以下哪个过程最快？还有其他方法可以存档吗？ 编辑：为简单起见，在此示例中，一首歌曲仅属于一个播放列表（多对一关系）。当然，也可以使用Junction Table，因此song⟷playlist是一个多对多关系（并在该表上应用上述策略之一）。