为什么新的 ASP.NET 标识表停止使用 Guid（唯一标识符类型）作为键？答案

【问题标题】：Why did the new ASP.NET Identity tables stop using Guid (uniqueidentifier type) as keys?为什么新的 ASP.NET 标识表停止使用 Guid（唯一标识符类型）作为键？
【发布时间】：2015-08-21 07:23:21
【问题描述】：

我试图了解为什么新的 ASP.NET 标识表停止使用 Guid（唯一标识符类型）作为键 - 而是现在使用 nvarchar(128)，但仍保留 Guid 作为 string。 ..

这不是很大的浪费吗？（uniqueidentifier 只是 2 个 integers 与整个 Guid 作为 36 个字符 string）

我怀疑实体框架可能对此负责......

改回唯一标识符键是否安全？

谁能告诉我使用 36 个字符串有什么好处？

【问题讨论】：

uniqueidentifier 是 16 个字节，而不是 8 个。字符串的大小不取决于它的长度，所以它实际上总是整个 256 个字节（nvarchar 每个“字符”有两个字节），对于任何索引和关联都是一样的。我想目标是灵活性，但这对我来说似乎是一个糟糕的权衡......
谢谢，由于某种原因，我有 Guid = 2 int 卡在我的脑海里......但我认为新的 SQL 服务器只分配正在使用的 nvarchar 字符数，而不是全部 128 如果只使用了 36 个 - 但仍然是一个很大的浪费......
我知道nvarchar(max) 可以做到这一点（即使这样也有一个最小长度 IIRC）和类似的，我还没有探索它是如何工作的。有可能他们解决了所有这些问题，但是我们不会简单地在任何地方使用nvarchar(max) 吗？ :D
我发现了另一个类似的讨论：stackoverflow.com/q/23891446/809357 - 那里有一些很好的答案。

标签： asp.net entity-framework entity-framework-6 asp.net-identity

【解决方案1】：

Identity 可在多个存储平台上运行，并非每个存储平台都将 Guid 作为受支持的存储类型。

您可以将默认字符串 pkey 更改为 Guid，但这涉及到您的 C# 模型上的一些工作。或者您可以将 pkey 更改为 int - 无论您喜欢什么。请注意，有一个巨大的debate 关于which 是better。

【讨论】：

谢谢。我想知道除了支持其他 SQL 平台之外，是否有更正当的理由使用 128 nvarchar...那种性能损失是不可接受的......
嗯，EF 可以在这些平台上模拟 GUID，但为什么到处都这样呢？这听起来像是 EF 提供的抽象应该处理的事情之一。
@Luaan “到处都这样”是什么意思？如果您在存储类中创建Guid 属性并告诉EF 使用它，它将在SQL Server 中创建UNIQUEIDENTIFIER 字段。将 Guid 存储为字符串是身份框架的一种选择。
@trailmax 哦，这是对 Yovav 评论的回应。例如。如果要支持不支持 guid 的数据库引擎，那应该是 EF 的工作，而不是 Identity 的工作。
EF 提供的不成熟...尝试存储一个应该转换为 tinyint 但 EF 将其转换为 int 的字节字段