20

Next to your normal user table "user"(user_id/user_email/user_pwd/etc), what is the best way to go to store profile information?

Would one just add fields to the user table like "user"

(user_id/user_email/user_pwd/user_firstname/user_lastname/user_views/etc)

or create another table called "profiles"

(profile_id/user_id/user_firstname/user_lastname/user_views/etc)

or would one go for a table with property definitions and another table to store those values?

I know the last one is the most flexible, as you can add and remove fields easily. But for a big site (50k users up) would this be fast?

bool.dev
  • 17,508
  • 5
  • 69
  • 93
renevdkooi
  • 1,515
  • 1
  • 17
  • 42

3 Answers3

38

Things to consider with your approaches

Storing User Profile in Users Table

  • This is generally going to be the fastest approach in terms of getting at the profile data, although you may have a lot of redundant data in here (columns that may not have any information in them).
  • Quick (especially if you only pull columns you need from the db)
  • Wasted Data
  • More difficult to work with / maintain (arguably with interfaces such as PHPMyAdmin)

Storing User Profile in User_Profile Table 1-1 relationship to users

  • Should still be quite quick with a join and you may eliminate some data redundancy if user profiles aren't created unless a user fills one in.
  • Easier to work with
  • Ever so slightly slower due to join (or 2nd query)

Storing User Profile as properties and values in tables

*i.e. Table to store possible options, table to store user_id, option_id and value*

  • No redundant data stored, all data is relevant
  • Most normalised method
  • Slower to retrieve and update data

My impression is that most websites use the 2nd method and store profile information in a second table, its common for most larger websites to de-normalize the database (twitter, facebook) to achieve greater read performance at the expense of slower write performance.

I would think that keeping the profile information in a second table is likely the way to go when you are looking at 50,000 records. For optimum performance you want to keep data that is written heavily seperated from data that is read heavy to ensure cache can work effectively.

neopickaze
  • 981
  • 8
  • 14
  • thank you for this clear explanation.I think together with iddqd's answer, I will mix it and go for that option. - user table / profile table / stats table. Don't know who to select as answer now... – renevdkooi Oct 08 '10 at 11:25
18

Table with property definitions isn't the good idea. I suggest to use three tables to store data:

user(id,login,email,pwd, is_banned, expired, ...) 
-- rarely changed, keep small, extremaly fast search, easy to cache, admin data
profile(id, user_id, firstname,lastname, hobby,description, motto)
--data often changed by user,...    
user_stats(id,user_id,last_login,first_login,post_counter, visit_counter, comment_counter)
--counters are very often updated, dml invalidate cache

The better way to store authorisation and authentication data is LDAP.

bool.dev
  • 17,508
  • 5
  • 69
  • 93
baklarz2048
  • 10,699
  • 2
  • 31
  • 37
7

You need way more than 3 tables. How will he store data like multiple emails, multiple addresses, multiple educational histories, multiple "looking for" relationships, etc. Each needs its own row assuming many values will be lookups like city, sex preference, school names, etc. so either normalize it fully or go the noSQL route, no point in hanging in the middle, you will lose the best of both worlds.

you can duplicate rows but it wont be good. social networks do not live with 50,000 users. either you will be successful and have millions of users or you will crash and clsoe it because to run these you need $$$ which will only come if you have a solid user base. With only 50,000 users for life investors wont invest, ad revenues wont cover the cost and you will close it. So design it like you want to be the next facebook right from day one. Think big!

Brian
  • 71
  • 1