Ihr erstes Schema ist die bessere Wahl der beiden. An dieser Stelle sollten Sie sich keine Gedanken über Leistungsprobleme machen. Sorgen Sie sich darum, ein gutes, flexibles und erweiterbares Design zu erstellen. Es gibt alle möglichen Tricks, die Sie später anwenden können, um Daten zwischenzuspeichern und Abfragen schneller zu machen. Ein weniger flexibles Datenbankschema zu verwenden, um ein Leistungsproblem zu lösen, das möglicherweise gar nicht erst auftritt, ist eine schlechte Entscheidung.
Außerdem werden viele (vielleicht die meisten) Umfrageergebnisse nur regelmäßig und von einer kleinen Anzahl von Personen (Veranstaltungsorganisatoren, Administratoren usw.) eingesehen, sodass Sie die Datenbank nicht ständig nach allen Ergebnissen abfragen müssen. Und selbst wenn Sie es wären, wird die Leistung in Ordnung sein. Wahrscheinlich würden Sie die Ergebnisse sowieso irgendwie paginieren.
Das erste Schema ist viel flexibler. Sie können standardmäßig Fragen wie Name und Adresse einschließen, aber für anonyme Umfragen konnten Sie sie einfach nicht erstellen. Wenn der Ersteller der Umfrage nur die Antworten aller auf drei von fünfhundert Fragen sehen möchte, ist das eine wirklich einfache SQL-Abfrage. Sie könnten ein kaskadierendes Löschen einrichten, um Antworten und Fragen automatisch zu löschen, wenn eine Umfrage gelöscht wird. Auch das Generieren von Statistiken wird mit diesem Schema viel einfacher.
Hier ist eine leicht modifizierte Version des von Ihnen bereitgestellten Schemas. Ich nehme an, Sie können herausfinden, welche Datentypen wohin gehören :-)
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
