10

所以我有一个用户收藏夹表。它们有几百万行。

目前,它们只有三列:id(pk)userIdsomeFkRef. 有一个索引userId可以让我快速选择用户的收藏夹。

目前这些是按顺序排列的id,实际上只是插入顺序。我们希望为用户提供重新排序他们的最爱的机会,最有可能通过某种拖放交互。

我的第一个(我怀疑是幼稚的)方法是简单地在 , 上添加一列order和一个复合索引。然而,经过反思,当用户将他们的项目在列表上移动一段距离时,项目的开始位置和结束位置之间的所有中间行都需要重新计算它们的列,因此也需要重新计算索引。userIdorderorder

这(很可能)很糟糕。

在我花了很长时间试图量化到底有多糟糕之前,我想知道是否有更好的基于表的表示,并且使用我上面描述的各种操作来操作更便宜。

4

3 回答 3

7

对于拖放交互,更好的选择是优先事项。您将从优先级 1、2、3 等开始,就像排序顺序一样。

但是随后,用户想要在 1 和 2 之间移动项目 5。瞧!给它1.5的值。无需更改其他值。索引更新负责其余的工作。

为此,需要将优先级存储为浮点数。这可能是个问题。此外,足够多的更改可能会导致浮点数的极限。因此,如果用户尝试获取最后一个元素并将其插入前两个元素之间,他/她可以逃脱大约几十次左右。

您可以使用从 1 开始定期为一个(或所有用户,如果是批量)重新分配编号的过程来解决此问题。

于 2013-02-27T17:21:44.840 回答
3

如果您不需要跨用户操作 someFkRef(例如,获取对某事感兴趣的用户列表),那么每个用户可能只有一条记录,以及 someFkRef (refA, refB) 的有序列表。

但这是一种非规范化的形式,并且由于它有一些缺点,它实际上取决于您的需求(以及您未来的需求,这就是麻烦所在)

于 2013-02-27T17:21:24.857 回答
1

不确定您对 ID 字段的依赖引用可能是什么,但您是否考虑过重写它?我认为有一个 SET IDENTITY INSERT = ON,或者你可以做的一些事情。

我意识到这是一件奇怪的事情,但考虑到你正在尝试做的事情,这可能是有道理的,并且会导致最少的开销。

于 2013-02-27T17:26:11.720 回答