I am making a web system using Asp.Net Core with individual user accounts (Identity), and I was thinking about how I should store the users' personal information in the database.

The system will have different kinds of users. Some are Members, some AdminUsers and some are ExternalResourcePersons (people). Each of the different user types have some exclusive fields that does not relate in any way to the other types.

For example, the Member-class might look something like this:

public class Member
    public Guid Id { get; set; }

    public int? MembershipId { get; set; }
    public Membership Membership { get; set; }

    public DateTime DateJoined { get; set; }
    public DateTime? DateLeft { get; set; }

    // public Guid PersonId { get; set; }
    // public Person Person { get; set; } // Which would contain contact information, DoB, etc.
    // OR:
    // public Guid ApplicationUserId { get; set; }
    // public ApplicationUser ApplicationUser { get; set; } // Which could be extended to contain contact info, DoB, etc.

    public List<MembershipFeeRegisteredPayment> RegisteredPayments { get; set; }

... while the AdminUser-class could be something like this:

public class AdminUser
    public Guid Id { get; set; }

    public bool CanLogIn { get; set; }
    public bool CanEditContent { get; set; }
    public bool CanPublishContent { get; set; }
    public bool CanManagePeople { get; set; }
    public bool CanManageMembers { get; set; }
    public bool CanManageExternalResourcePeople { get; set; }
    public bool CanManageAdminUsers { get; set; }
    public bool CanManageSiteSettings { get; set; }

    // public Guid PersonId { get; set; }
    // public Person Person { get; set; }
    // OR:
    // public Guid ApplicationUserId { get; set; }
    // public ApplicationUser ApplicationUser { get; set; }

Should I extend the ApplicationUser-class with fields like FirstName, LastName, Street, Zip, DateOfBirth, etc. (up to about 20 fields), or put all that in a related Person-class?

Or maybe it doesn't matter, and it's really up to me? Is it faster to load a user's complete record if it's all in one table, and I wouldn't have to load any related data? Is there something I haven't thought of when it comes to maintainability?

  • Sounds like Person is a sUperclass. Jun 2, 2021 at 15:30

2 Answers 2


Both ways might be appropriate. The way to determine which is to examine your use cases and how you would support the data requirements for each. For example:

  • A user can enter a person's last name and can view a list of all admins, members, and external resources that match. A separate Person table would support this better, since you can index everything over a single field in a single table.
  • The application checks permissions with each transaction. A separate Person table would support this better, because its would allow the application to load permissions without loading the demographic data, improving performance.
  • A person can be both an administrator and a member. A separate Person table would support this better; separate tables would require you to duplicate data.

Your use cases may vary.


This question comes up in almost every example dealing with the representation of people in IT systems, and I should probably try to look up previous questions to which this one is a duplicate. Here's one example, I'm not sure whether it's similar enough to count as a duplicate: Enterprise application object oriented modeling for user and role.

Basically, you need to distinguish between Person and Role.

Person attributes are mostly related to identity, and in the context of computer systems, to authentication. Of course you should only keep data you need for the system in question, which will often be the name, password and e-mail, sometimes birth date and home address, less often shoe size etc.

Role attributes include authorization info as well as relations the person has to other objects in the system, for example when an admin only has rights over part of the data, or when a person can be member of multiple groups.

Since Roles can vary wildly, you need to decide whether they can all be represented in one database table (with potentially unused fields for some Roles) or in separate tables for each kind of role.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.