我必须为一个非常大的网站提供会员解决方案。该站点将使用ASP.NET MVC 2和MS SQL2008数据库构建。
目前的会员提供商看起来似乎有点过分，功能太多了。
我想要存储的是电子邮件/密码和基本个人资料信息，例如First / LastName，电话号码。我只需要2个角色，管理员和用户。
考虑到可能有数百万用户注册，您对这种情况有何建议？ StackOverflow使用什么？
我过去经常使用现有的会员API，并将其扩展到存储其他信息等。但是有表格，如
aspnet_Applications
aspnet_Paths
aspnet_SchemaVersions
aspnet_WebEvent_Events
aspnet_PersonalizationAllUsers
aspnet_PersonalizationPerUser
这是非常多余的，我从来没有找到用途。
修改
为了澄清@drachenstern回答后的一些其他冗余，还有一些额外的列，我在Membership / Users表中没有用，但会添加到每个select / insert语句的有效负载中。
此外，我听说GUID并不是那么快，而且更愿意使用整数（就像Facebook一样），这也是公开曝光的。
如何创建自己的 成员资格提供程序 ，重新使用部分成员资格API （验证，密码加密，登录Cookie等） 但仅限于符合我要求的表格？
欢迎链接到文章和现有实施，我的谷歌搜索返回了一些非常基本的例子。
提前致谢
马尔科
答案 0 :(得分：13)
@Marko我当然可以理解，标准会员制可能包含比你需要的功能更多的功能，但事实是它确实无关紧要。您不会使用会员系统的某些部分，就像您将不会使用的部分.Net一样。有很多东西可以做.Net可以做你永远不会使用的东西，但你不会通过.Net并删除你的功能吗？当然不是。你必须把注意力集中在那些对你要完成的事情很重要的事情上。不要陷入分析的瘫痪状态。你将浪费你的时间，旋转你的车轮，而不是最终为你创造的东西。现在微软有时会弄错，但他们确实做了很多事情。您不必拥抱他们为实现目标所做的一切 - 您只需要了解对您的需求有何重要意义。
至于Guids和ints作为主键，让我解释一下。主键和聚簇索引之间存在重要差异。您可以在不属于主键的列上添加主键和聚簇索引！这意味着，如果通过名称（或其他）排列数据更为重要，则可以自定义聚簇索引以准确反映所需内容而不会影响主键。让我用另一种方式说 - 主键和聚簇索引不是同一个。我写了一篇关于如何添加聚簇索引然后将主键添加到表中的博客文章。聚簇索引将按照您需要的方式对表行进行物理排序，主键将强制执行您需要的完整性。看看我的博客文章，看看你究竟如何做到这一点。
以下是链接 - http://iamdotnetcrazy.blogspot.com/2010/09/primary-keys-do-not-or-should-not-equal.html。
这非常简单，您只需添加聚簇索引FIRST，然后添加主键SECOND。必须按顺序完成，否则您将无法执行此操作。当然，这假定您使用的是Sql Server。大多数人都没有意识到这一点，因为SQL Server默认会在主键上创建聚簇索引，但您只需先添加聚簇索引，然后添加主键，就可以了。当您的数据库和服务器系统向外扩展时，使用int作为主键可能会成为非常棘手的问题。我建议使用Guids并添加聚集索引以反映实际需要存储数据的方式。
现在，总而言之，我只想告诉你要创造一些伟大的东西，不要陷入表面细节的困扰，这些细节不会给你足够的性能提升。生命太短暂。此外，请记住，您的系统只能与最慢的代码一样快。因此，请确保您查看实际上需要花费大量时间并处理这些事情的事情。
还有一件事。你不能把你在网上看到的所有东西都拿到面值。技术随时间而变化。有时你可能会查看很久以前有人写过的问题的答案，这个问题今天已经不再适用了。此外，人们将回答问题并向您提供信息，而无需实际测试他们所说的内容，看是否真实。您可以为您的应用程序做的最好的事情是对它进行压力测试。如果您使用的是ASP.Net MVC，则可以在测试中执行此操作。您可以做的一件事是添加一个for循环，在测试中将用户添加到您的应用程序，然后进行测试。这是一个想法。还有其他方法。你只需要付出一些努力来设计你的测试，或者至少为你的目的设计好。
祝你好运！
答案 1 :(得分：5)
目前的会员提供商看起来似乎有点过分，功能太多了。
我想要存储的是电子邮件/密码和基本个人资料信息，例如First / LastName，电话号码。我只需要2个角色，管理员和用户。
然后只使用那部分。它不会使用您不使用的部件，并且您可能会发现您需要其他部件。这些类已经存在于.NET框架中，因此您无需提供任何许可或任何内容。
数据库的大小非常小，如果您喜欢我，并且将aspnetdb保留给自己，那么您实际上并没有从其他数据库中获取任何内容。
您是否有令人信服的理由使用第三方组件而不是框架内的内容？
修改：
我还有额外的列 没有用在 Membership / Users表，但是哪个 会增加每个的有效载荷 选择/插入语句。
MobilePIN PasswordQuestion / PasswordAnswer（我会的 做基于邮件的密码恢复） IsApproved（用户永远是 批准） 评论MobileAlias 用户名/ LoweredUsername（或 电子邮件/ LoweredEmail）[电子邮件是 用户名，所以只需要其中的一个]
听起来你正试图microoptimize。传递空字符串几乎没有成本（好吧，它就在那里，但是你必须要知道它花了多少钱。每个用户不会那么多）。我们通常也不会在我们的应用程序中使用所有这些字段，但我们使用会员系统而没有可测量的不利影响。
此外，我听说Guid并不是那么快，而且更愿意使用整数（就像Facebook那样）也会公开曝光。
我听说过cookiemonster喜欢cookies。同样，如果没有剖析，你不知道这是否有害。通常人们使用GUID，因为他们希望它绝对（绝对程度）绝对唯一，无论何时创建。每个用户生成ONCE的成本并不是那么重。不是在您创建新帐户时。
由于您完全从头开始创建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在他的书中详细介绍了这一点，这对你来说是一个很好的参考。
答案 2 :(得分：3)
我的建议是基准测试。添加您认为在生产中将拥有的记录数量，并提交与生产中相同数量的请求，并查看它对您的环境的影响。
我的猜测是没关系，你所谈论的开销是微不足道的。