Why is the User information stored in two different tables in ASP.NET's default Membership Provider?

Question

There are two tables: aspnet_users and aspnet_membership. Can anyone elaborate on the reasons why they don't use a single table for this?

Answer 1

Some of the other providers in ASP.NET (other than the Membership provider) also store user-specific information. e.g. Profile.

More information about this:

Several of the shipped ASP.NET providers store/use information in the context of a user name. One of these is MembershipProvider, which provides an authentication store and set of services.

Another is ProfileProvider, which allows user-specific data to be held against each user.

You can still use ProfileProvider regardless of whether or not you have chosen to use MembershipProvider. Because ProfileProvider must store data against a user name (i.e. as exposed by the Context.User.Identity.Name property), it will go ahead and add a user record into aspnet_Users.

Hopefully this clarifies the reason for the separation.

Answer 2

Honestly it doesn't make much sense to me either. It seems as though the aspnet_Membership table was set up to house user/Application level information but UserID is a PK. Very strange. Perhaps there were setting themselves up for a situation where you do have multiple applications per user in some later release.

Dave mentions that there are other tables like aspnet_Profile that hold user specific info. It could be that the ASP.NET 2.0 folks were just trying to separate out different groupings of fields into more easily digestible chunks.

I know it's just a bunch of conjecture. Hopefully someone with some actual knowledge will chime in.

Answer 3

The membership table holds information related to the MembershipProvider API interface. The users table stores usernames and user ids, which are referenced from many providers.

• Users
  • Membership (MembershipProvider)
  • Profile (ProfileProvider)
  • Roles (RoleManager)
  • etc

The aspnetdb system is very modular and each piece can be customized through the various providers. The tables need to be separated so each interface can be rewritten, redirected, etc.

Answer 4

I found this explination from this page:

The SqlMembershipProvider stores user account information in two related tables:

• aspnet_Users - has a record for each user account, storing the bare essentials. The UserId column uniquely identifies each user in the system, and is stored as a uniqueidentifier (a GUID).

• aspnet_Membership - has a UserId column that ties each record back to a particular record in aspnet_Users. The aspnet_Membership table stores core data associated with every user account: Email, Password, the security question and answer, and so on.

Answer 5

The aspnet_users contains the users you create (authentication FORMS) ... NOTE THET when your authentication is set to WINDOWS, the users are WINDOWS users e.g. domain\firstname.lastname

The aspnet_membership contains membership preference information used in stuff like WebParts and user settings

Answer 6

Please excuse me if the answer to my question is too obvious but if for any user we delete the corresponding record from the "aspnet_membership" table, would the user details in the master table i.e. "aspnet_users" along suffice? How the user will even be able to login to the system without a password? Can anybody elaborate?