Първата ви схема е по-добрият избор от двете. В този момент не трябва да се притеснявате за проблеми с производителността. Тревожите се за създаването на добър, гъвкав, разширяем дизайн. Има всякакви трикове, които можете да направите по-късно, за да кеширате данни и да направите заявките по-бързи. Използването на по-малко гъвкава схема на база данни за решаване на проблем с производителността, който може дори да не се материализира, е лошо решение.
Освен това много (може би повечето) резултати от проучването се преглеждат само периодично и от малък брой хора (организатори на събития, администратори и т.н.), така че няма да правите постоянно запитвания в базата данни за всички резултати. И дори да сте, изпълнението ще бъде добре. Вероятно ще разместите резултатите по някакъв начин.
Първата схема е много по-гъвкава. По подразбиране можете да включите въпроси като име и адрес, но за анонимни анкети просто не можете да ги създавате. Ако създателят на анкетата иска да види само отговорите на всички на три от петстотин въпроса, това е наистина проста SQL заявка. Можете да настроите каскадно изтриване за автоматично изтриване на отговори и въпроси, когато анкета бъде изтрита. Генерирането на статистически данни също ще бъде много по-лесно с тази схема.
Ето една леко модифицирана версия на схемата, която сте предоставили. Предполагам, че можете да разберете кои типове данни къде отиват :-)
surveys
survey_id (index)
title
questions
question_id (index, auto increment)
survey_id (link to surveys->survey_id)
question
responses
response_id (index, auto increment)
survey_id (link to surveys->survey_id)
submit_time
answers
answer_id (index, auto increment)
question_id (link to questions-question_id)
answer
