为什么ASP.NET Identity 2.0使用GUID /字符串作为用户ID？

Question

正如标题所说,我想知道为什么ASP.NET Identity 2.0使用带有GUID的字符串作为用户表的主要群集密钥.这对整数id有什么好处吗？我只看到问题,GUID不是聚簇索引的最佳选择.

我错过了什么或者整数仍然是更好的选择吗？

Answer 1

关于guid的使用,有一种观点认为,为了将标识符与其周围的数据完全分开,促使使用没有"含义"的id; 从数据存储区外部看不到此ID.如果我们查看代理键的某些特征,我们有以下内容

• 该值在系统范围内是唯一的,因此永远不会重复使用
• 该值是系统生成的
• 该值不可由用户或应用程序操纵
• 该值不包含语义含义
• 该值对用户或应用程序不可见
• 该值不是由来自不同域的多个值组成.

因此,guid符合该法案,因为它确实是由系统生成的,并且与域无关.我认为使用guid主要是这种特殊思维方式的趋势问题; 但是,由于它们引入了一种新的"可扩展主键"机制,因此可以更改密钥,因此您可以使用PK的整数回退.

关于业绩我会点你这个线程在接受回答说:

GUID似乎是您主键的自然选择 - 如果您真的必须,您可能会争辩将其用于表的PRIMARY KEY.我强烈建议不要使用GUID列作为群集密钥,默认情况下SQL Server会执行此操作,除非您明确告知不要这样做.

你真的需要分开两个问题:

• 主键是一个逻辑构造 - 一个候选键,它唯一且可靠地标识表中的每一行.这可以是任何东西,真的 - 一个INT,一个GUID,一个字符串 - 选择对你的场景最有意义的东西.
• 集群密钥(在表上定义"聚集索引"的一列或多列) - 这是一个与物理存储相关的东西,在这里,一个小的,稳定的,不断增加的数据类型是你最好的选择 - INT或BIGINT作为您的默认选项.

这完全证实了你的印象.

Answer 2

其他答案非常好,但是我没有看到的一个优点是Guid.NewGuid()(理论上)创建了一个唯一的ID而没有将行提交给数据库.

基于整数的标识列需要数据库刷新才能获取其ID.在某些情况下,在代码中生成行的PK并将其传递给数据库是很有用的(显然,还有其他方法可以通过唯一约束实现此目的,但Guid是一个相当不错的选择).