Is it OK to store all personal details in AspNetUsers table when using ASP.NET Identity?

David Anderson 196 Reputation points

I have just added user authentication to an existing Web Forms application using ASP.NET Identity. During this process, I learned how to add additional columns to the AspNetUsers table (for RegistrationDate and LastLoginTime).

The only personal details I am currently storing in that table are UserName and Email. Would there be any disadvantages to adding all other personal information, such as postal address, telephone no, mobile no, etc, or is that data better stored in a separate table that is unconnected with the Identity class?

One advantage I can see for a separate Users table would be a UserID that was a simple integer rather than the Id of AspNetUsers (e.g. db44251d-c17e-4dc1-95f8-d1dd7b9a26d8).

A set of technologies in the .NET Framework for building web applications and XML web services.
1,479 questions
ASP.NET Web Forms
ASP.NET Web Forms
A part of the ASP.NET web application framework that can be used to create ASP.NET web applications.
550 questions
{count} votes

2 answers

Sort by: Most helpful
  1. AgaveJoe 22,626 Reputation points

    EDIT: Either AspNetUsers or a new Users table would still have to have a one-to-many relationship with a Salutations table (Mr, Mrs, etc) and a Payments table.

    I don't know your application requirements and can only make general recommendations based on past experience. If you do not need a one to many relationship then storing the user information in the AspNetUser table is fine.

    For example, payments commonly consist of a billing and shipping address. I don't know if shipping applies to your application.

  2. David Anderson 196 Reputation points

    As an additional question, is there any reason why I shouldn't change the name of the Id column (the PK) in the AspNetUsers table? I would prefer to have a more self-explanatory name of UserId.

    EDIT: I've just looked more closely at the PK/FK naming convention for the ASP.NET Identity tables. Where a table has a single PK (as in AspNetUsers and AspNetRoles), it is always called Id, but when this is used as a FK in another table it is given a more informative name that reflects its source, i.e. UserId and RoleId. Simply following that convention resolves my issue.