I’m working on a application where each user has to fill out an extensive profile for themselves.
The first part of the user profile consists of about 25 or so fields of general information
The next section of the user profile is a section where they evaluate themselves on a set list of criteria. ie, “Rate how good you are at cooking” and then they tick a radio box from one to five, there is also a check box that the can check if they are ‘extra interested’ in the activity/subject they rated themselves on.
There are about 40 of these that they rate themselves on.
So my question is, how should I store this information, should there be columns in my users table for every field and item? This would be nearly 70 fields
or should I setup a table for user_profile, and user_self_evaluation, and have the columns for each in there and have a one-one relationship with the users?
Use separate tables. In this way when you update only self evaluation, you does not need to update the user_profile table. The idea here is to separate the often updated fields in another table, leaving the rarely updated on another location. If the table became large, and the username/password is in separate table, the performance of lookup by userid / username won’t be affected by the large amount of update queries, nor you’ll bring the whole site down if you alter the self_evaluation table.
But if you are planning to add new evaluations, I’d suggest a different design:
user_profile table with the 25 profile field
self_evaluations table, with id and name, and any meta information about the question; with 1 record per evaluation
user_profile_evaluation with userid, evaluationid, score, extra – with one record for each evaluation of the user.
This way your schema will be much more flexible and you won’t need to alter the table in order to add another evaluation.