数据库设计 – 如何设计用于存储排序列表的数据库？

>插入(x) – 将记录x插入表中
>删除(x) – 从表中删除记录x
> Before(x,n) – 返回记录x之前的’n’记录
排序清单.
> After(x,n) – 返回记录x后面的’n’个记录
排序清单.
> First(n) – 从排序列表中返回第一个’n’个记录.
> Last(n) – 从排序列表中返回最后的’n’条记录.
>比较(x,y) – 给出表中的两个记录x和y,找出x>
年.

我能想到的简单方法是在表中存储某种“rank”属性,并通过对该属性进行排序来进行查询.但是在这种方法中,插入/修改具有等级的记录变成了昂贵的操作.有更好的方法吗？

具体来说,我希望使用Amazon的SimpleDB实现该表.但是关系数据库的一般答案也应该有所帮助.

负载配置文件更新：

由于我计划将其用于Web应用程序,因此它取决于使用该应用程序的用户数量.

如果有100k活跃用户(超级乐观：P),那么我每天的近似估计就是

500k选择,100k插入和删除,500k更新

我希望桌子总共增长到500k.

我希望优化更新,插入和比较操作.项目的排名将不断变化,我需要更新表格.

解决方法

如果它是数据的任意属性,则应将其存储为记录表中的列.假设Amazon的SimpleDB与典型的RDBMS类似,那么您可以将此列编入索引,并使用适当的索引策略快速满足上述所有查询.这对于RDBMS来说是正常的.

鉴于您期望高插入和更新活动,以及相对较高的读取活动,我建议您执行以下操作：

>将表格集中在排名上,特别是如果绝大多数查询都是针对排名的话.如果没有,或者如果在SimpleDB中没有选择聚类键,则只需创建一个以rank作为前导列的索引.这将满足查询3-6.
>首先记录索引然后排名(或者,在SQL Server世界中,只记录和包含排名,或者只是记录,如果你已经在排名上聚集)将满足查询7.
>可以通过适当地间隔数据来优化操作1和2(即在SQL Server中设置FILLFACTOR).如果您按等级进行聚类,这一点尤为重要.
>当您插入或更新排名时,尽可能保持排名数之间的差距,以最大限度地减少您需要重新排名现有记录以适应排名插入或更新的可能性.例如,如果您以1000为单位对记录进行排名,则会留下足够的空间来进行大约一半的更改和插入,并且您需要重新排名不直接参与这些更改的记录.
>每晚重新排列所有记录以重置它们之间的排名差距.
>您可以调整批量重新排名的频率以及排名间隙大小,以适应相对于现有记录数量的预期插入或更新数量.因此,如果您有100K记录并期望您的插入和更新为10％,请为10K新排名留出足够的空间并每晚重新排名.
>重新排名500K记录是一项昂贵的操作,但是对于像这样的数据库来说,每天或每周休息一小时应该很好.这个非工作时间的大规模重新排名以维持排名差距,这可以节省您在正常和高峰时段为每个排名更新或插入重新排名的记录.

如果您希望在100K大小的表上读取100K,我建议不要使用链接列表方法.它不能很好地扩展到那些尺寸.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!