Question

My application database has a Groups table that separates users into logical roles and defines access levels (admin, owner, salesperson, customer service, etc.)

Groups has many Users. The Users table contains login details such as username and password.

Now I wish to add user profiles to my database. The trouble I’m having (probably due to my relative unfamiliarity with proper database normalization) is that different user groups have different kinds of profiles. Ergo, a salesperson’s profile will include his commission percentage, whereas an admin or customer service would not need this value.

So, would the proper method be to create a unique profile table for each group? (e.g. admin_profiles, or salesperson_profiles). or is there a better way that combines certain details in a generic profile, while some users have extended info. And if so, whats a good example of how to do this with the commission example given?

Answer 1

In a case like this where these profiles are truly defined by real-world criteria, I would probably suggest using tables dedicated to each type. In the interest of full disclosure, though, you could use an EAV system to store these. Something akin to:

User:
    UserID
    ...
    ProfileID

Profile:
    ProfileID
    Name

Criteria:
    CriteriaID
    Name

ProfileCriteria:
    ProfileID
    CriteriaID

UserCriteria:
    UserID
    CriteriaID

The Profile table defines the parent table for profiles. You’d have one row in this for each of your profile types.

Criteria defines the basic criteria that can exist on a profile, regardless of which profile (for example, you may have the same criteria on more than one profile).

CriteriaProfile serves to create a m:m relationship between Profile and Criteria. This is also where you’d add things like sorting for a criteria within a particular profile.

UserCriteria points to a user’s specific values for a given criteria. This would also allow you to switch profiles for a user and maintain any criteria that were common by just deleting those that were not part of the new profile.

HOWEVER

EAV structures come with a lot of overhead to maintain. Instead of relying on the RDBMS’s facilities for managing structured data (which is what people are paid a lot of money to come up with), you now have to manage it yourself. Tables tend to get very large substantially faster than with non-EAV systems, as you have many times the number of rows (as you now have a row for what would have been every column in a normal structure).

EAV’s are powerful and flexible, but not always the solution. If your profiles need to be dynamic, then they can be a suitable tool.