database schema for storing questionnaires and multiple choice answers

Question

We need some help in designing database schema for questionnaires and multiple choice answers.

The first options is to design a question table and an answer table like below

 * Question Table
   - question_id    auto integer
   - question       varchar

 * Answer Table
   - user_id        integer
   - question_id    integer
   - answer         integer 

However, the issue with this design is that, when a user submit answers to questionnaires, multiple rows need to be inserted and hence both write as well retrieving will be slower. Also, the table will grow very big. However, the advantage is that it's expandable and new questions can be added easily.

Another approach is to have all the answers in one row but in different column, like this

 * Answer Table
   - user_id        integer
   - answer_1       integer 
   - answer_2       integer 
   ...
   - answer_n       integer 

Advantage is that, at a time only one row to write or retrieve and hence it will be much faster than the first approach. However, schema will be rigid and if any new questions is added, db schema will have to be changed to accomodate a new column.

We have over 3 million users and multiple questionnaires per user. Hence the speed is definitely a criterion. Based on this criterion, which one do you prefer? Any other alternatives?

Thanks

Answer 1

The intended denormalization you propose in the second case will certainly yield some performance gains. The big question is if you need to be able to search through data efficiently - you may not be able to, let's say, collect advanced statistics on answers (ie how many people gave between 3 and 6 answers).

If you don't need statistics, the second option is better (performance-wise). If you do, maybe you should stick to the normal form.

A compromise is using JSON instead of columns to store data. Results may be stored in something like PostgreSQL's jsonb column, which may be queried easily. Your question is tagged mysql , though, so I don't know if it's an option for you.