I am just wondering why they split up the users stuff into 2 tables. Like they got aspnet_ membership and aspnet_users.
Is it just because the membership stuff they have is so long?
+2
A:
It's for securing multiple applications from a single user database; aspnet_membership has UserId and ApplicationId so each user can have a different password for multiple applications (and also be locked out of one application but not another).
pjabbott
2009-09-28 23:17:08
That's true, but the other table has that information as well, so you haven't answered why the two different tables exist.
Rex M
2009-09-28 23:20:14
+3
A:
It's to separate identity/authentication management from membership management. The "big" user table is the actual identity repository - e.g., if you want to use SQL to store your identity data, it all goes in here. But you may want to use some other source - say, Active Directory - to be your identity repository. You validate identity and authentication against that instead, but you still need to have some way to join the SQL-based role/membership data to the AD-based identity data. That's where the smaller table comes in - just enough info to maintain those relationships.
Rex M
2009-09-28 23:18:31
I am ditching asp.net membership because alot of tables I don't need and since I done some stuff I have rendered all the built in method useless. So I am trying to figure out if I should split the data like this or stick it into one table. What is the recommended approach?
chobo2
2009-09-28 23:30:00
@Chobo2 hard to say without knowing your needs. I'd say though that if the ASP.NET provider does everything you need and a lot you don't need - you might want to stay with it. Building your own is a cost you could be spending on better things. But, if there's some specific functionality you need, then design your provider to your need first.
Rex M
2009-09-29 01:29:01