Suppose I have a table named Survey, primary key is survey_id. For each survey in the table, it has some 200 questions (rows). My app will want to generate reports on these by aggregating these 200 or so questions (such as standard deviation for each question) of various users' answers, stored in a different table named SurveyResult, pk on user_id, survey_id. Each survey can vary on the number of columns but won't be a huge difference.

My question is, should I implement table SurveyResult as a 'fat' table with the pk, and 200 columns, or should I do a 'long' table where I add an additional survey_question_id to its pk and each question answer by each user on each survey represents a row?

A 'fat' table makes aggregating results easier (by eg. SELECT STDEV(q1), AVG (q2), ... FROM SurveyResult WHERE survey_id = x). On the other hand, a 'long' table seems more of the rdbms design's "norm" (I hardly see many databases have 'fat' tables).

Greatly appreciate your opinions!

Hi Make a long table instead because I might answer only 50 questions out of 200. In that case it would be quite efficient to process record. I had a problem like this some time ..What I did is have long time....and a table having userid,questions_answered,total_questions,correct_ questions, category_of_questions like wise..... Have a PL/SQL code to calculate the result once after users submits data....
I hope that gives some assistance........