0

I'm currently using Django 1.5.1 and using a custom user as described in the official documentation. I realized everything is stored under one table, the auth_user one.

My question is, why is it better to have everything in one big table, instead of having 2 tables like it used to be prior to 1.5 by using a user_profile table for all additional data? It seems smarter the way it used to be, in case we want to add 20 new fields for information about the user, it is weird to have everything in auth_user.

In my case, for now I have class MyUser(AbstractUser) with 2 additional fields gender and date_of_birth, so it's all good with this, but now I would like to have many other information (text fields) like "favorite movies", "favorite books", "hobbies", "5 things I could not live without", etc. etc., to have way more information about my user. So I was just wondering if I should put that under MyUser class, or should I define a UserProfile one? And why?

Thanks!

Dachmt
  • 2,079
  • 4
  • 29
  • 45

1 Answers1

1

When you have it all in one table, then database access is faster. With the old way you had to join on the auxiliary table to get all the information of the user.

Usually when you see a One-to-One relation, it would be better just to merge them in one table.

But the new custom User model solves also another problem, which is what atributes a User should have? What attributes are essential for your application? Is an email required? Should the email be also the username with which a user logs in?

You couldn't do these stuff before this feature was introduced.

Regarding your question about where to put additional user information like "hobbies" and such, it really depends on how often you will query/need this attributes. Are they gonna be only on the user's profile page? Well then you could have them in a seperate table and there wouldn't be much problem or performance hit. Otherwise prefer to store them on the same table as the User.

rantanplan
  • 7,283
  • 1
  • 24
  • 45
  • Ok, thanks for the explanation. For now, I use the username as primary mandatory field, not the email. But for login the user I created a custom EmailBackend to check on both the username and email address, to be able to use both when authenticating. But I clearly see why this custom user helps here, it's really nice. – Dachmt Sep 05 '13 at 00:11
  • Regarding what I should use, it's mostly a social app where people check out other people profiles, so these information will be display more than often, pretty intensively even. Do you still think it's better to store everything under the custom user table then? – Dachmt Sep 05 '13 at 00:13
  • @Dachmt Well in a site like here, for example, I would store them in a separate table. In your situation it depends. Could the `favorite movies` be denormalized in each own table, to avoid duplication? Would it involve users rating their movies? Then probably yes. But it depends on the function of each of those attributes. If I had a somewhat definitive set of semi-informational attributes that don't go beyond 20-30, I'd put them in the same table. – rantanplan Sep 05 '13 at 00:21
  • It would be stored as text, so `favorite movies` could look like "I like this movie A for that, and also movie B because of the actors, but both are the best movies ever!" or "Movie A, Movie, B", it really depends on what the person wants to put but it would be a textfield, free to put anything you want (can be blank). So no duplication cases here. And I'd say I'll have probably 20 additional parameters at max (~10 for gender, date of birth, religion, weight, etc, and ~5 to 10 for more general questions by filling up a text field for "favorites things to do", "favorites movies and books", etc) – Dachmt Sep 05 '13 at 00:34
  • @Dachmt yeah well it sounds to me like putting it in the same table would be the best choice. Also taking into consideration that profile cheking is gonna be a prime function, we can certainly assume is going to perform much better. – rantanplan Sep 05 '13 at 00:39
  • Ok, so keeping my current implementation and adding my fields in my `MyUser` class. Thanks for the advices and explanation @rantanplan! – Dachmt Sep 05 '13 at 00:59