我必须为一个非常大的网站提出一个会员解决方案。该网站将使用 ASP.NET MVC 2 和 MS SQL2008 数据库构建。
当前的会员资格提供商似乎有点过分了，功能太多了。
我想要存储的只是电子邮件/密码和基本个人资料信息，例如名字/姓氏、电话号码。我只需要 2 个角色：管理员和管理员。用户。
考虑到可能有数百万用户注册，您对这种情况有何建议？ StackOverflow 使用什么？
我过去经常使用现有的会员 API，并对其进行了扩展以存储附加信息等。但是有些表
aspnet_Applications
aspnet_Paths
aspnet_SchemaVersions
aspnet_WebEvent_Events
aspnet_PersonalizationAllUsers
aspnet_PersonalizationPerUser
非常多余，我从未发现有什么用处。
编辑
只是为了澄清 @drachenstern 回答后的一些其他冗余，还有一些额外的列，我在会员/用户表中没有用处，但它们会添加到每个选择/插入语句的有效负载。
- MobilePIN
- 密码问题/密码答案 （我将进行基于电子邮件的密码恢复）
- 已批准 （用户将始终获得批准）
- 评论
- MobileAlias
- 用户名/LoweredUsername （或电子邮件/LoweredEmail） [电子邮件是用户名，所以只需要其中之一]
此外，我听说 GUID 不是那么快，并且更喜欢使用整数（就像 Facebook 那样），这也会公开暴露。
我如何创建自己的会员提供程序，重新使用一些会员 API（验证、密码加密、登录 cookie 等） > 但仅限于满足我要求的表格？
非常欢迎文章和现有实现的链接，我的谷歌搜索返回了一些非常基本的示例。
提前致谢
马尔科
I have to come up with a membership solution for a very large website. The site will be built using ASP.NET MVC 2 and a MS SQL2008 database.
The current Membership provider seems like a BIG overkill, there's way too much functionality.
All I want to store is email/password and basic profile information such as First/LastName, Phone number. I will only ever need 2 roles, administrators & users.
What are your recommendations on this type of scenario, considering there might be millions of users registered? What does StackOverflow use?
I've used the existing Membership API a lot in the past and have extended it to store additional information etc. But there's tables such as
aspnet_Applications
aspnet_Paths
aspnet_SchemaVersions
aspnet_WebEvent_Events
aspnet_PersonalizationAllUsers
aspnet_PersonalizationPerUser
which are extremely redundant and I've never found use for.
Edit
Just to clarify a few other redundancies after @drachenstern's answer, there are also extra columns which I have no use for in the Membership/Users table, but which would add to the payload of each select/insert statements.
- MobilePIN
- PasswordQuestion/PasswordAnswer (I'll do email based password recovery)
- IsApproved (user will always be approved)
- Comment
- MobileAlias
- Username/LoweredUsername (or Email/LoweredEmail) [email IS the username so only need 1 of these]
Furthermore, I've heard that GUID's aren't all that fast, and would prefer to have integers instead (like Facebook does) which would also be publicly exposed.
How do I go about creating my own Membership Provider, re-using some of the Membership APIs (validation, password encryption, login cookie, etc) but only with tables that meet my requirements?
Links to articles and existing implementations are most welcome, my Google searches have returned some very basic examples.
Thanks in advance
Marko
发布评论
评论（3）
@Marko我当然可以理解标准会员系统可能包含比您需要的更多的功能，但事实是这并不重要。会员系统的某些部分您不会使用，就像您不会使用 .Net 的某些部分一样。 .Net 可以做很多你永远不会使用的事情，但你不会通过 .Net 并删除这些功能，是吗？当然不是。你必须专注于对你想要完成的事情重要的事情，并从那里开始工作。不要陷入分析的瘫痪之中。你会浪费你的时间，转动你的轮子，最终不会得到比已经为你创造的更好的东西。现在，微软有时确实会犯错，但他们确实在很多事情上做对了。您不必接受他们为实现您的目标所做的一切 - 您只需了解什么对您的需求来说是重要的。
至于Guids和int作为主键，让我解释一下。主键和聚集索引之间有一个至关重要的区别。您可以在不属于主键的列上添加主键和聚集索引！这意味着，如果按名称（或其他名称）排列数据更为重要，您可以自定义聚集索引以准确反映您需要的内容，而不会影响您的主键。让我换一种方式来说——主键和聚集索引不是同一个。我写了一篇关于如何向表添加聚集索引和主键的博客文章。聚集索引将按照您需要的方式对表行进行物理排序，并且主键将强制您需要的完整性。请查看我的博客文章，了解具体的操作方法。
这是链接 - http： //iamdotnetcrazy.blogspot.com/2010/09/primary-keys-do-not-or-should-not-equal.html。
这非常简单，您只需首先添加聚集索引，然后添加主键即可。必须按该顺序完成，否则您将无法执行此操作。当然，这假设您正在使用 Sql Server。大多数人没有意识到这一点，因为 SQL Server 默认情况下会在主键上创建聚集索引，但您所要做的就是先添加聚集索引，然后添加主键，然后就可以了。当数据库和服务器系统横向扩展时，使用整数作为主键可能会变得非常有问题。我建议使用 Guid 并添加聚集索引来反映您实际需要的数据存储方式。
现在，总而言之，我只是想告诉您去创造一些伟大的东西，不要陷入肤浅的细节，这些细节不会给您带来足够的性能提升，而这些细节实际上很重要。生命太短暂了。另外，请记住，您的系统的速度只能与其最慢的代码一样快。因此，请确保您查看那些实际上占用大量时间的事情并处理好它们。
还有一件事。您不能仅从表面上理解您在网络上看到的所有内容。技术随着时间的推移而变化。有时，您可能会看到某人很久以前写的问题的答案，但现在已不再相关。此外，人们会回答问题并为您提供信息，而无需实际测试他们所说的内容是否属实。您能为您的应用程序做的最好的事情就是对其进行很好的压力测试。如果您使用 ASP.Net MVC，则可以在测试中执行此操作。您可以做的一件事是添加一个 for 循环，将用户添加到测试中的应用程序中，然后进行测试。这是一个想法。还有其他方法。您只需要付出一点努力就可以很好地设计您的测试，或者至少足够好地满足您的目的。
祝你好运！
@Marko I can certainly understand that the standard membership system may contain more functionality than you need, but the truth is that it really isn't going to matter. There are parts of the membership system that you aren't going to use just like there are parts of .Net that you aren't going to use. There are plenty of things that .Net can do that you are never, ever going to use, but you aren't going to go through .Net and strip out that functionality are you? Of course not. You have to focus on the things that are important to what you are trying to accomplish and work from there. Don't get caught up in the paralysis of analysis. You will waste your time, spin your wheels and not end up with anything better than what has already been created for you. Now Microsoft does get it wrong sometimes, but they do get a lot of things right. You don't have to embrace everything they do to accomplish your goals - you just have to understand what is important for your needs.
As for the Guids and ints as primary keys, let me explain something. There is a crucial difference between a primary key and a clustered index. You can add a primary key AND a clustered index on columns that aren't a part of the primary key! That means that if it is more important to have your data arranged by a name (or whatever), you can customize your clustered index to reflect exactly what you need without it affecting your primary key. Let me say it another way - a primary key and a clustered index are NOT one in the same. I wrote a blog post about how to add a clustered index and then a primary key to your tables. The clustered index will physically order the table rows the way you need them to be and the primary key will enforce the integrity that you need. Have a look at my blog post to see exactly how you can do it.
Here is the link - http://iamdotnetcrazy.blogspot.com/2010/09/primary-keys-do-not-or-should-not-equal.html.
It is really simple, you just add the clustered index FIRST and then add the primary key SECOND. It must be done in that order or you won't be able to do it. This assumes, of course, that you are using Sql Server. Most people don't realize this because SQL Server will create a clustered index on your primary key by default, but all you have to do is add the clustered index first and then add the primary key and you will be good to go. Using ints as a primary key can become VERY problematic as your database and server system scales out. I would suggest using Guids and adding the clustered index to reflect the way you actually need your data stored.
Now, in summary, I just want to tell you to go create something great and don't get bogged down with superficial details that aren't going to give you enough of a performance gain to actually matter. Life is too short. Also, please remember that your system can only be as fast as its slowest piece of code. So make sure that you look at the things that ACTUALLY DO take up a lot of time and take care of those.
And one more additional thing. You can't take everything you see on the web at face value. Technology changes over time. Sometimes you may view an answer to a question that someone wrote a long time ago that is no longer relevant today. Also, people will answer questions and give you information without having actually tested what they are saying to see if it is true or not. The best thing you can do for your application is to stress test it really well. If you are using ASP.Net MVC you can do this in your tests. One thing you can do is to add a for loop that adds users to your app in your test and then test things out. That is one idea. There are other ways. You just have to give it a little effort to design your tests well or at least well enough for your purposes.
Good luck to you!
然后只需使用该部分即可。它不会使用您不使用的部件，并且您可能会发现您将来需要这些其他部件。这些类已存在于 .NET 框架中，因此您无需提供任何许可或任何内容。
该数据库的大小非常小，如果您像我一样，将 aspnetdb 留给自己，那么您实际上并没有从其他数据库中获取任何内容。
您是否有令人信服的理由使用第三方组件而不是框架中已有的组件？
编辑：
这听起来像是您正在尝试微优化。传递空字符串实际上是没有成本的（好吧，它就在那里，但你必须分析一下才能知道它要花多少钱。每个用户不会花那么多）。我们通常也不会在应用程序中使用所有这些字段，但我们使用会员系统并没有产生可衡量的有害影响。
我听说饼干怪物喜欢饼干。同样，如果没有分析，您不知道这是否有害。通常人们使用 GUID 是因为他们希望它绝对（在一定程度上绝对）唯一，无论它何时创建。每个用户生成一次的成本并不是那么高。当您已经为他们创建新帐户时就不会了。
由于您绝对要从头开始创建 MembershipProvider，因此这里有一些参考：
http://msdn.microsoft.com/en-us/library/system.web.security.membershipprovider.aspx
https://web.archive.org/web/20211020202857/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 在他的书中详细介绍了这一点，这对您来说是一个很好的参考。
Then just use that part. It's not going to use the parts that you don't use, and you may find that you have a need for those other parts down the road. The classes are already present in the .NET framework so you don't have to provide any licensing or anything.
The size of the database is quite small, and if you do like I do, and leave aspnetdb to itself, then you're not really taking anything from your other databases.
Do you have a compelling reason to use a third-party component OVER what's in the framework already?
EDIT:
This sounds like you're trying to microoptimize. Passing empty strings is virtually without cost (ok, it's there, but you have to profile to know just how much it's costing you. It won't be THAT much per user). We already routinely don't use all these fields in our apps either, but we use the membership system with no measurable detrimental impact.
I've heard that the cookiemonster likes cookies. Again, without profiling, you don't know if that's detrimental. Usually people use GUIDs because they want it to be absolutely (well to a degree of absoluteness) unique, no matter when it's created. The cost of generating it ONCE per user isn't all that heavy. Not when you're already creating them a new account.
Since you are absolutely set on creating a MembershipProvider from scratch, here are some references:
http://msdn.microsoft.com/en-us/library/system.web.security.membershipprovider.aspx
https://web.archive.org/web/20211020202857/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 goes into detail on that in his book and it's a good reference for you to have as is.
我的建议是您对其进行基准测试。添加您认为在生产中将拥有的尽可能多的记录，并提交与在生产中获得的类似数量的请求，并查看它在您的环境中的执行情况。
我的猜测是没问题，你所说的开销是微不足道的。
My recommendation would be for you to benchmark it. Add as many records as you think you will have in production and submit a similar number of requests as you would get in production and see how it performs for your environment.
My guess is that it would be OK, the overhead that you are talking about would be insignificant.