大表的最佳主键格式

Question

我正在开发一个具有一些潜在大型数据表的asp.net应用程序。我想知道定义主键的最佳方法是什么。我知道之前有人问过，但由于这是针对特定情况的，我认为这个问题是有效的。

我在SQL Server 2008数据库上使用Entity Framework 4。

定义主键有哪些可能性，请考虑以下因素：

1. 有可能随着时间的推移，记录数量将超过32位边界，因此无法实现自动增量整数。
2. 无法在表格中的其他列的组合上定义主键。
3. 出于数据同步的原因，应用程序生成的id优先于数据库生成的id。此外，在EF中，它意味着额外往返数据库以检索新生成的id。
4. 对于插入性能，最好使用顺序键。
5. 我认为（顺序）guid的空间要求是一个缺点。
6. 对于字符串id，最好不区分大小写。

到目前为止，我自己想出的是一个自定义算法，它生成一个日期时间部分和一个随机部分，转换为十六进制字符串表示。这让我的字符串略短于guid。我仍然可以将它转换为base64，但这将违反项目nr.6。

感谢您的建议。

Answer 1

您可以考虑将密钥存储为BIGINT（8字节整数）。

BIGINT的工作方式与INT完全相同，可以相同的方式在自动递增标识列中使用。

Answer 2

以下是一些想法。

• 考虑大小为5或6字节的binary数据类型。
• 不要忽视partitioned tables的好处，特别是对于大型桌子。
• 保持其余列尽可能小。有时star schema可以帮助解决这个问题。

遗憾的是，您无法创建二进制数据标识列。但是，您可以使用max(Id)+1插入策略。我对.NET的实体框架并不熟悉，但应该有一种方法可以在同一行程中检索密钥。我在过去看过文档，解释了如何将实体映射到存储过程并从中检索密钥，但我没有任何细节。

Answer 3

我会在你的情况下使用顺序GUID。

• 这是代理密钥
• 它是应用程序生成的，因此在插入
后无需检索数据库生成的id
• 它是顺序的，适用于聚簇索引
• 如果你可能溢出32位密钥，你可能不得不使用64位密钥（除了你设法创建和使用48位密钥或类似的东西） - 然后128位GUID只需要两倍的空间
• 字符串代理键对我来说有些不自然，我看不到GUID键的好处