用于超大型应用程序的 ASP.NET 自定义成员资格提供程序

Question

我必须为一个非常大的网站想出一个会员解决方案。该站点将使用 ASP.NET MVC 2 和 MS SQL2008 数据库构建。

当前的会员资格提供者似乎有点矫枉过正，功能太多了。

我只想存储电子邮件/密码和基本的个人资料信息，例如名字/姓氏、电话号码。我只需要 2 个角色，管理员和用户。

考虑到可能有数百万用户注册，您对这种情况有何建议？ StackOverflow 使用什么？

我过去经常使用现有的 Membership API，并对其进行了扩展以存储其他信息等。但是有诸如

之类的表格

aspnet_Applications
aspnet_Paths
aspnet_SchemaVersions
aspnet_WebEvent_Events
aspnet_PersonalizationAllUsers
aspnet_PersonalizationPerUser

这是非常多余的，我从来没有发现用处。

编辑
只是为了澄清@drachenstern 的回答后的一些其他冗余，在 Membership/Users 表中还有一些我没有用的额外列，但它们会添加到每个 select/insert 语句的有效负载中。

1. 手机密码
2. PasswordQuestion/PasswordAnswer （我会根据电子邮件恢复密码）
3. IsApproved （用户将始终被批准）
4. 评论
5. MobileAlias
6. 用户名/LoweredUsername （或电子邮件/LoweredEmail） [email 是用户名，因此只需要其中 1 个]

此外，我听说 GUID 并不是那么快，而是更喜欢使用整数（就像 Facebook 一样），这也会公开。

如何创建自己的会员资格提供者，重新使用一些会员资格 API（验证、密码加密、登录 cookie 等） 但只有符合我要求的表格？

欢迎提供文章和现有实现的链接，我的 Google 搜索返回了一些非常基本的示例。

提前致谢
马尔科

Answer 1

@Marko 我当然可以理解标准会员系统可能包含比您需要的更多的功能，但事实是它真的无关紧要。会员系统的某些部分您不会使用，就像 .Net 的某些部分您不会使用一样。 .Net 可以做很多你永远不会使用的事情，但你不会通过 .Net 并去掉这些功能，是吗？当然不是。您必须专注于对您要完成的工作和从那里开始工作很重要的事情。不要陷入分析的瘫痪。你会浪费你的时间，转动你的轮子，并且不会得到比已经为你创造的更好的东西。现在微软有时确实会出错，但他们确实做对了很多事情。你不必接受他们为实现你的目标所做的一切——你只需要了解什么对你的需求很重要。

至于 Guids 和 int 作为主键，让我解释一下。主键和聚集索引之间有一个关键的区别。您可以在不属于主键的列上添加主键和聚集索引！这意味着，如果按名称（或其他名称）排列数据更重要，您可以自定义聚集索引以准确反映您的需要，而不会影响主键。让我换一种说法 - 主键和聚集索引不是同一个。我写了一篇关于如何向表中添加聚集索引和主键的博客文章。聚集索引将按照您需要的方式对表行进行物理排序，并且主键将强制执行您需要的完整性。看看我的博客文章，看看你是怎么做到的。

这是链接 - http://iamdotnetcrazy.blogspot.com/2010/09/primary-keys-do-not-or-should-not-equal.html。

其实很简单，你只需先添加聚集索引，然后添加主键 SECOND。必须按此顺序完成，否则您将无法完成。当然，这假设您使用的是 Sql Server。大多数人没有意识到这一点，因为 SQL Server 默认会在你的主键上创建一个聚集索引，但你所要做的就是先添加聚集索引，然后添加主键，你就可以了。随着您的数据库和服务器系统向外扩展，使用整数作为主键可能会变得非常有问题。我建议使用 Guids 并添加聚集索引以反映您实际需要存储数据的方式。

现在，总而言之，我只想告诉你去创造一些伟大的东西，不要被表面的细节所困扰，这些细节不会给你带来足够的性能提升，而实际上并不重要。人生如此短暂。另外，请记住，您的系统只能与最慢的代码一样快。因此，请务必查看实际会占用大量时间的事情并妥善处理这些事情。

还有一件事。你不能把你在网上看到的所有东西都看成表面上的价值。技术随着时间而变化。有时，您可能会查看某人很久以前写的问题的答案，但现在已不再相关。此外，人们会回答问题并向您提供信息，而无需实际测试他们所说的内容是否真实。您可以为您的应用程序做的最好的事情就是对它进行非常好的压力测试。如果您使用的是 ASP.Net MVC，您可以在测试中执行此操作。您可以做的一件事是添加一个 for 循环，在测试中将用户添加到您的应用程序，然后进行测试。这是一个想法。还有其他方法。您只需要付出一点努力就可以很好地设计您的测试，或者至少足以满足您的目的。

祝你好运！

Answer 2

当前的会员资格提供者似乎有点矫枉过正，功能太多了。

我只想存储电子邮件/密码和基本的个人资料信息，例如名字/姓氏、电话号码。我只需要 2 个角色，管理员和用户。

然后就使用那部分。它不会使用您不使用的部分，并且您可能会发现以后需要其他部分。这些类已经存在于 .NET 框架中，因此您不必提供任何许可或任何东西。

数据库的大小非常小，如果你像我一样，将 aspnetdb 留给它自己，那么你并没有真正从其他数据库中获取任何东西。

您是否有令人信服的理由使用第三方组件而不是框架中已有的内容？

---

编辑：

我还有一些额外的列 没有用在 Membership/Users 表，但是哪个 将添加到每个的有效负载 选择/插入语句。

手机密码 PasswordQuestion/PasswordAnswer（我会 做基于电子邮件的密码恢复） IsApproved（用户将始终 得到正式认可的） 评论 MobileAlias 用户名/LoweredUsername（或 电子邮件/LoweredEmail) [电子邮件是 用户名，所以只需要其中 1 个]

这听起来像是你在尝试microoptimize。传递空字符串实际上是没有成本的（好吧，它就在那里，但你必须分析一下它会花费你多少钱。每个用户不会那么多）。我们通常也不会在我们的应用程序中使用所有这些字段，但我们使用会员系统不会产生可衡量的不利影响。

此外，我听说 Guid 并不是那么快，而是更喜欢使用整数（就像 Facebook 一样），这也会公开。

我听说 cookiemonster 喜欢饼干。同样，如果没有分析，您不知道这是否有害。通常人们使用 GUID 是因为他们希望它绝对（在一定程度上绝对）唯一，无论它是何时创建的。每个用户生成一次的成本并不是那么高。当您已经为他们创建了一个新帐户时，则不会。

---

既然您完全准备从头开始创建 MembershipProvider，这里有一些参考资料：

http://msdn.microsoft.com/en-us/library/system.web.security.membershipprovider.aspx

http://www.4guysfromrolla.com/articles/120705-1.aspx

http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx

http://www.amazon.com/ASP-NET-3-5-Unleashed-Stephen-Walther/dp/0672330113

Stephen Walther 在他的书中对此进行了详细介绍，您可以按原样进行参考。

Answer 3

我的建议是您对其进行基准测试。添加您认为在生产中将拥有的尽可能多的记录，并提交与生产中相似数量的请求，并查看它在您的环境中的表现。

我的猜测是没关系，您所说的开销将是微不足道的。