应对数据库身份/自动编号最大化的策略

时间:2009-04-16 11:32:27

标签: database database-design types identity future-proof

自动编号字段(例如,SQL Server中的“标识”)是为数据库表提供唯一键的常用方法。但是,鉴于它们非常普遍,将来 ,我们将处理它们将开始达到其最大值的问题。

是否有人知道或有推荐的策略来避免这种情况?我希望很多答案都会建议转换为guid,但考虑到这将需要大量的开发(特别是在许多系统集成并共享价值的情况下)还有另外一种方法吗?我们是否朝着更新的硬件/操作系统/数据库只允许更大和更大的整数值的方向前进?

5 个答案:

答案 0 :(得分:11)

如果您确实希望自己的ID用完,请使用bigint。对于大多数实际用途,它不会用完,如果确实如此,你应该使用uniqueidentifier

如果您每秒有 30亿(这意味着3.0GHz处理器上的交易/周期)交易,bigint耗尽大约一个世纪(甚至如果你为标志稍微放了一点。)

那就是说,“ 640K ought to be enough for anybody”:)

答案 1 :(得分:2)

请参阅以下相关问题:

接受/最高投票的答案几乎涵盖了它。

答案 2 :(得分:0)

是否有可能循环从数据库中删除的数字?或者大部分记录还活着?只是一个想法。

我的另一个想法是Mehrdad建议改用bigint

答案 3 :(得分:0)

标识列通常设置为从1开始并递增+1。负值与正值一样有效,从而使可用标识符池加倍。

答案 4 :(得分:0)

如果您获得的数据量如此之大,以至于您的ID最大化,您可能还希望获得复制支持,以便您可以以多种方式同步数据库实例。

对于此类情况,以及您希望避免使用“可猜测”ID(Web应用程序等)的情况,我建议使用Guids(Uniqueidentifiers),默认使用新Guid作为标识列的替代。< / p>

由于Guids是唯一的,因此即使将记录同时添加到系统中,它们也可以正确地同步数据。