Why is separation of user and profile data considered good?

Question

Hello. I've been reading this question and felt that I don't quite agree with the statement Separation of user and profile data is a nice touch.

As I see it, profile data, such as, e.g. country or whatever belongs in the user object, while separating such data into profile leads to creating a new object (and table) with 1-to-1 relation to the user object. Is such separation considered a good practice merely because of aesthetic reasons? (You see only user input data in one table and generated data is in another)

Answer 1

Well, that's only if you assume that the user and profile have 1-to-1 relationship.

If this is guaranteed to always be the case, than the reason for separation might be purely aesthetic, however there still might be performance reasons for separating the two.

For instance, profile data can be accessed by other users, can often be cached without much consideration for quick invalidation, etc.

They are conceptually different kinds of data - even if they have 1-to-1 relationship. I would never cache user login details - but then I wouldn't expose it programnatically to modules that merely require profile data.

That's the rationale if 1-to-1 relationship can be guaranteed to hold. Can it?

If you allow multiple login credentials (or multiple login methods) per user, it now becomes more interesting. For instance, cookie-based sessions often are stored in a volatile storage on the server side (there is rarely a need for persistence of that data). Would you have that information pointing to the user object, or to the profile object?

You can have a one-directional relationship - there is a pointer from User to Profile, but not from Profile to User. This way, modules holding the Profile data cannot change login details.

Finally, what if you use a solution like facebook, allowing multiple login emails per user, and say additionally login through OpenID and through an iPhone/Android app? would you then agree that Profile and User is still the same?

Answer 2

Pros:

1. You can freely change profile table schema and do not bother if it breaks user.
2. You can reuse authentication/authorization logic in other apps.
3. You can link one user to different profiles, and even to other apps.
4. Better performance due to small amounts of data in user entity (applies to DB storage, where less columns in table is better) during authentication operations and other user-only operations which do not require profile data.

Cons:

1. One more DB table or other data entity to store profile
2. You have to maintain relation between profile and user data.
3. More code.
4. Performance drop may occur when accessing profile data.

For example, Django (Python web framework) provides auth mechanism and you can add up your very own profile mechanism.

Generally if profile is small and will never be subject to modifications you can save it alongside user data. If profile schema may be altered in future or if it contains lots of data then it's better to separate user and profile.

Answer 3

There are a few reasons I can think of to split up user data:

1. Separating authorization from information. This is something I would strongly recommend. Once the user is authenticated, you only look at the user profile. By separating the authorization part, you can easily go from a password login, to adding Facebook Connect, OpenID authentication, etc. without having to do any changes to the user profile objects.
2. Separating public and private data. In high-security databases, you may want to encrypt the private data using private keys (so only the user themselves could ever read the data), while still being able to access the public data as another user.
3. For performance reasons. If you have huge amounts of data on the user, you may want to put data that is rarely accessed by itself, so that indexes can be optimized for data that is often looked up.

Answer 4

If you have a public API (like, for example, twitter or facebook have), you would like to return only the user details, and not the user object (containing the protected data). That can be done either by having separate entities, or by having a DTO.

Answer 5

For me the user is: Login (Username), Password, Role and is used to do all the security related stuff.

The "profile" is additional information to the user, that should be placed in a separat object.

And consider: in some cases a user can have more than one profile...

Answer 6

Mainly because profile data is not needed if one wishes to just know who created some entity. The only real place that needs a users profile is primarily when the system wishes to customise something for that user when they are on the system. Imagine the profile had the users favourite colour this is immaterial to many or all other uses of the application.