适用于非常大的应用程序的ASP.NET自定义成员

Question

我必须为一个非常大的网站提供会员解决方案.该站点将使用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语句的有效负载中.

1. MobilePIN
2. PasswordQuestion/PasswordAnswer (我会做基于电子邮件的密码恢复)
3. 已批准(用户将始终获得批准)
4. 评论
5. MobileAlias
6. 用户名/ LoweredUsername (或Email/LoweredEmail) [email是用户名,因此只需要其中的1个]

此外,我听说GUID并不是那么快,而且更愿意使用整数(就像Facebook那样),这也是公开曝光的.

我如何创建自己的成员资格提供程序,重新使用一些成员资格API (验证,密码加密,登录cookie等),但只能使用符合我要求的表格？

我们非常欢迎链接到文章和现有实施,我的谷歌搜索返回了一些非常基本的例子.

在此先感谢
Marko

Answer 1

@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循环,在测试中将用户添加到您的应用程序,然后进行测试.这是一个想法.还有其他方法.您只需要花一点力气来设计好您的测试,或者至少为您的目的做好.

祝你好运!

Answer 2

目前的会员提供商看起来似乎有点过分,功能太多了.

我要存储的只是电子邮件/密码和基本个人资料信息,例如First/LastName,电话号码.我只需要2个角色,管理员和用户.

然后只使用那部分.它不会使用您不使用的部件,并且您可能会发现您需要其他部件.这些类已经存在于.NET框架中,因此您无需提供任何许可或任何内容.

数据库的大小非常小,如果你喜欢我,并将aspnetdb保留给自己,那么你实际上并没有从你的其他数据库中获取任何东西.

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

编辑:

还有一些额外的列,我在Membership/Users表中没有用,但是会添加到每个select/insert语句的有效负载中.

MobilePIN PasswordQuestion/PasswordAnswer(我将进行基于电子邮件的密码恢复)IsApproved(用户将始终被批准)评论MobileAlias用户名/ LoweredUsername(或Email/LoweredEmail)[email是用户名,因此只需要其中1个]

这听起来像你想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在他的书中对此进行了详细介绍,这对你来说是一个很好的参考.