StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<blockquote> <p>The current Membership provider seems like a BIG overkill, there's way too much functionality.</p> <p>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.</p> </blockquote> <p>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.</p> <p>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.</p> <p>Do you have a compelling reason to use a third-party component OVER what's in the framework already?</p> <hr> <p><strong>EDIT</strong>:</p> <blockquote> <p>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.</p> <p>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]</p> </blockquote> <p>This sounds like you're trying to <a href="https://stackoverflow.com/questions/2978460/practical-rules-for-premature-optimization">microoptimize</a>. 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. </p> <blockquote> <p>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.</p> </blockquote> <p>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.</p> <hr> <p>Since you are absolutely set on creating a MembershipProvider from scratch, here are some references:</p> <p><a href="http://msdn.microsoft.com/en-us/library/system.web.security.membershipprovider.aspx" rel="nofollow noreferrer">http://msdn.microsoft.com/en-us/library/system.web.security.membershipprovider.aspx</a></p> <p><a href="http://www.4guysfromrolla.com/articles/120705-1.aspx" rel="nofollow noreferrer">http://www.4guysfromrolla.com/articles/120705-1.aspx</a></p> <p><a href="http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx" rel="nofollow noreferrer">http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx</a></p> <p><a href="http://rads.stackoverflow.com/amzn/click/0672330113" rel="nofollow noreferrer">http://www.amazon.com/ASP-NET-3-5-Unleashed-Stephen-Walther/dp/0672330113</a></p> <p>Stephen Walther goes into detail on that in his book and it's a good reference for you to have as is.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload