CODEWITHSUNDEEP
database-schemaextensibilityuser-profile
user576796
user576796

Reputation: 137

User profile database design

i have to design a user account/profile tables for a university project. The basic idea i have is the following:

  1. a table for user account (email, username, pwd, and a bunch of other fields)
  2. a user profile table.

It seems to me that there are two ways to model a user profile table:

  1. put all the fields in a table [UserProfileTable]

    UserAccountID (FK)
UserProfileID (PK)
DOB            Date
Gender         (the id of another table wich lists the possible gender)
Hobby          varchar(200)
SmallBio       varchar(200)
Interests      varchar(200)

    ...

  2. Put the common fields in a table and design an ProfileFieldName table that will list all fields that we want. For example:

    [ProfileFieldNameTable]

ProfileFieldID int (PK)  
Name           varchar

Name will be 'hobby', 'bio', 'interests' etc...Finally, we will have a table that will associate profiles with profile fields:

[ProfileFieldTalbe]
ProfileFieldID   int (PK)
UserProfileID    FK    FK
FieldContent     varchar

'FieldContent' will store a small text about hobbies, the bio of the user, his interests and so on.

This way is extensible, meaning that in this way adding more fields corresponds to an INSERT.

What do you think about this schema?

One drawback is that to gather all profile information of a single user now i have to do a join.

The second drawback is that the field 'FieldContent' is of type varchar. What if i want it to be of another type (int, float, a date, a FK to another table for listboxs etc...)?

Upvotes: 3

Views: 4276

Answers (1)

gmhk
gmhk

Reputation: 15940

I suggest 2nd option would be better, The drawbacks which you mentioned are not actual drawbacks,

Using JOINS is one of ways to retrieving the data from the 1 or more tables ,

2) 'FieldContent' is of type varchar : I understand that you are going to create only 'FieldContent' for all your other fields

In that case, I suggest that you can have 'FieldContent' for each corresponding fields so that you can give any any kind of Data Type which you wish.

Coming to the first option,

1)If you put all the fields in one table may lead lot of confusion and provides less feasibility to extend later, if any requirements changes

2)There will be lot of redundancy as well.

Upvotes: 2

Related Questions