使用内置的 asp.net 身份验证提供程序是一个坏主意，因为 guid 被用作主键等
我正处于一个项目阶段，需要扩展 ASP.NET MVC 网站中的用户成员资格字段。
我经历了这些不同的思维过程。
使用“用户名”将用户加入记录。这是一个非常糟糕的主意，因为用户想要更改他们的用户名等。
然后我想我可以将 userId 的 guid 连接到其他表。
然后我想，如果我将来需要使用 id 作为简单对象，那么使用 guid 可能会不好。所以我建立了一个链接表来将guid连接到整数。
决定我不需要它，所以回到使用 guid 将事物链接在一起，这使得请求更简单。
决定阅读大量关于使用 guid 作为聚集索引时性能糟糕的讨论。
我现在很困惑，这是否意味着默认的 asp.net 身份验证对性能来说很糟糕？
我知道人们不应该太早考虑性能，但我确实希望最终这个应用程序会非常受欢迎，所以如果我必须“推出自己的”身份验证提供程序，我想也许我应该现在就这样做。
任何有关实际执行此操作的方向的链接将不胜感激，因为由于 asp.net 会员资格人员为我做了所有事情，所以我已从中抽象出来。
谢谢大家。
I'm at the stage in a project where I need to extend the user membership fields in a asp.net mvc website.
I have gone through these different thought processes.
Using "username" to join users to records. Very bad idea due to a user wanting to change their username etc.
Then I thought I could connect the guid of userId to the other tables.
Then I thought that using guid might be bad if I needed to use the id as a simple in the future. So I was setting up a link table to joing guid to ints.
Decided that i didn't need that so went back to using guid to link things together, which makes requests more simple.
Read loads of discussions of performance being hideous when using guid as clustered index.
I'm now confused, does this mean that the default asp.net authentication is awful for performance?
I know one shouldn't think about performance too soon, but I do hope to end up with this app being very popular, so if I have to "roll my own" authentication provider, I guess maybe I should do it now.
Any links in the direction of actually doing this would be greatly appreciated as I have been abstracted from this due to asp.net membership stuff doing everything for me.
Thanks everyone.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您担心默认 aspnet 会员资格提供程序使用
GUID的性能，只需实现您自己的会员资格提供程序并使用int Identity(1,1)主键PK。编写您自己的成员资格提供程序非常简单，而且说实话，如果
GUIDPK 是您唯一关心的默认实现，那么 下载内置提供程序的源代码并将代码更改为使用整数而不是 GUID。完成此操作最多不应超过一个小时。要完成此图，请在数据库上运行 aspnet_sql.exe 以获取成员资格数据库，然后更改表和存储过程以匹配您对源所做的更改。以下是有关实现成员资格提供程序的 MSDN 文档
Just implement your own Membership provider and use an
int identity(1,1)Primary Key if you're concerned about the performance of the default aspnet Membership provider's use of aGUIDPK.Writing your own Membership Provider is really straightforward and to be honest, if the
GUIDPK is the only thing that concerns you about the default implementation, then download the source for the built-in provider and change the code to use integers instead of GUIDs. This shouldn't take more than an hour max to do. To complete the picture, run aspnet_sql.exe on your database to get the Membership database and then alter the tables and sprocs to match the changes you make to the source.Here's the MSDN documentation on implementing a Membership Provider
Guid 是比 int 或 bigint 更糟糕的选择，这在任何地方都有讨论和记录。他们可怕吗？并不真地。有一些应用程序对每个键和外键使用指南的恐怖故事，但它们是例外。
指南的独特性有其优点，如果明智地使用，它们可以毫无问题地完成工作。我更愿意使用使用 guid 的默认提供程序实现，而不是自己推出。掌握正确的技能并且比默认技能更好是非常重要的。我并不是以贬义的方式这么说，但如果您需要指导来理解指导对性能的影响，那么您可能还没有准备好自己动手。
使用默认的，测试它，测量然后决定，我的 2c。
Guids are a worse choice than ints or bigints, this was discussed and documented inany places. Are they horrible? Not really. There are horror stories of apps using guids for every key and foreign key and what have you, but they are the exception.
The uniqueness of guids has it's advantages and when used judiciously they can get the job done without issues. I'd much rather use the default provider implementation using guids than roll your own. The skillset to roll your own correct and better than the default one is significant. I don't say this in a derogatory way, but if you need guidance on understanding the guid impact on erformance then you're probably not ready to roll your own.
Use the default one, test it, measure and then decide, my 2c.