Twój pierwszy schemat jest lepszym wyborem z dwóch. W tym momencie nie powinieneś martwić się problemami z wydajnością. Martw się o wykonanie dobrego, elastycznego i rozszerzalnego projektu. Istnieje wiele sztuczek, które możesz wykonać później, aby buforować dane i szybciej wykonywać zapytania. Używanie mniej elastycznego schematu bazy danych w celu rozwiązania problemu z wydajnością, który może nawet się nie zmaterializować, jest złą decyzją.
Poza tym wiele (być może większość) wyników ankiet jest przeglądanych tylko okresowo i przez niewielką liczbę osób (organizatorów wydarzeń, administratorów itp.), więc nie będziesz stale przeszukiwać bazy danych w celu uzyskania wszystkich wyników. A nawet gdybyś był, występ będzie w porządku. Prawdopodobnie i tak podzieliłbyś wyniki na strony.
Pierwszy schemat jest znacznie bardziej elastyczny. Możesz domyślnie dołączyć pytania, takie jak imię i nazwisko oraz adres, ale w przypadku anonimowych ankiet po prostu nie możesz ich tworzyć. Jeśli twórca ankiety chce wyświetlić tylko odpowiedzi wszystkich na trzy pytania z pięciuset, to jest to naprawdę proste zapytanie SQL. Możesz skonfigurować usuwanie kaskadowe, aby automatycznie usuwać odpowiedzi i pytania po usunięciu ankiety. Dzięki temu schematowi generowanie statystyk będzie znacznie łatwiejsze.
Oto nieco zmodyfikowana wersja podanego schematu. Zakładam, że możesz dowiedzieć się, jakie typy danych idą gdzie :-)
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
