为什么新的ASP.NET身份表停止使用Guid（uniqueidentifier类型）作为键？ [英] Why did the new ASP.NET Identity tables stop using Guid (uniqueidentifier type) as keys?

问题描述

我想了解为什么新的ASP.NET身份表停止使用 Guid （uniqueidentifier type）作为键 - 而是现在使用 nvarchar（128）但仍然保持 Guid 作为字符串 ...

这不是一个巨大的浪费吗？ （ uniqueidentifier 只是2 整数 vs整个 Guid as一个36个字符 string ）

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

是否可以安全地转回独特的识别键？

任何人都可以告诉我使用36个字符的好处是什么字符串？

解决方案

身份是建立在多个存储平台上工作的，而不是每个存储平台都有Guid作为支持的存储类型。

您可以将默认字符串pkey更改为Guid，但这涉及到C＃模型的一些工作。或者您可以将pkey更改为int - 无论您喜欢什么。请注意，有一个关于辩论 =http://blogs.msdn.com/b/sqlserverfaq/archive/2010/05/27/guid-vs-int-debate.aspx =nofollow noreferrer>哪个是更好。

I'm trying to understand why the new ASP.NET Identity tables stopped using Guid (uniqueidentifier type) as keys - instead it is now using nvarchar(128) but still keep a Guid as a string...

Isn't it a huge waste? (uniqueidentifier is just 2 integers vs the whole Guid as a 36 character string)

I'm suspecting that Entity Framework might be responsible for this...

Is it safe to change back to uniqueidentifier keys?

Can anyone tell me what are the benefits of using 36 character strings?

解决方案

Identity is built to work on multiple storage platforms and not every storage platform has Guid as a supported storage type.

You can change the default string pkey into Guid, but that involves some work on your C# models. Or you can change the pkey into an int - whatever you like. Just be aware that there is a huge debate about which is better.

这篇关于为什么新的ASP.NET身份表停止使用Guid（uniqueidentifier类型）作为键？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！