Has a rough database schema for the SO users/membership ever been published? I've seen that the Data Explorer shows the following columns for a user:

  1. Id
  2. Reputation
  3. CreationDate
  4. DisplayName
  5. LastAccessDate
  6. WebsiteUrl
  7. Location
  8. AboutMe
  12. EmailHash
  13. Age

OpenID and the standard ASP.NET Membership don't play so nicely together, yet SO has an excellent user-friendly sign up/in process. I'd love someone to share how the SO Membership and User tables are architected.

Notably, the DisplayName is case sensitive (i.e. 'Junto' and 'junto' are two different users) and standard ASP.NET Membership lower-cases all usernames before checking for dupes. Therefore it suggests that they have written a Custom Membership provider, especially since they have the possibility of having multiple OpenId logins tied to the one account.

Would anyone like to have a guess at the database schema? It would be interesting to see how this is done correctly.

  • 2
    Note that "Junto" and "Junto" can also be separate users. – John Oct 21 '11 at 16:00
  • I would not consider using the Membership Provider for any large or complex site, as it tries to be "all things for all people". – Ian Ringrose Oct 21 '11 at 21:14
  • @John. Thanks I didn't realise that. – Rebecca Oct 26 '11 at 15:27
  • @Ian Ringrose I'd like to hear more! – Rebecca Oct 26 '11 at 15:27

Download the Stack Exchange Data Explorer, the software that runs http://data.stackexchange.com.

From it you can obtain a lot of code that is shared with the "normal" Q&A platform, including user management/registration/login but even things like markdown parsing, routing, database structure, etc.

It was an invaluable resource for me while learning ASP.NET.

  • I think I just got a little over excited. Superb. Looks like the FormAuthentication ticket is issued manually. No ASP.NET Membership to be seen. IsAdmin flag on the user is the only roles type stuff. Event the table schemas are listed. You made my Friday. :-) – Rebecca Oct 21 '11 at 16:26
  • @Junto: I had a similar reaction when I discovered how many "general purpose" things it had that I could learn =) – Thomas Bonini Oct 21 '11 at 16:33
  • @Junto to confirm : we simply do not use the membership provider; the user-identity code is bespoke – Marc Gravell Oct 21 '11 at 20:58
  • @Mark Gravell Was the reason behind the decision due to the fact that the standard ASP.NET Membership is clunky and slow, or simply that it wasn't a good fit for a multiple identity, single user account model? – Rebecca Oct 26 '11 at 15:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .