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)
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?