Je eerste schema is de betere keuze van de twee. Op dit moment hoeft u zich geen zorgen te maken over prestatieproblemen. Maak je geen zorgen over het maken van een goed, flexibel, uitbreidbaar ontwerp. Er zijn allerlei trucs die u later kunt doen om gegevens in de cache op te slaan en query's sneller uit te voeren. Het gebruik van een minder flexibel databaseschema om een prestatieprobleem op te lossen dat zich misschien niet eens voordoet, is een slechte beslissing.
Bovendien worden veel (misschien de meeste) onderzoeksresultaten slechts periodiek en door een klein aantal mensen (organisatoren van evenementen, beheerders, enz.) bekeken, dus u zult niet constant in de database zoeken naar alle resultaten. En zelfs als je dat was, zal de uitvoering prima zijn. Je zou de resultaten waarschijnlijk toch op de een of andere manier pagineren.
Het eerste schema is veel flexibeler. U kunt standaard vragen zoals naam en adres opnemen, maar voor anonieme enquêtes kunt u deze eenvoudigweg niet maken. Als de maker van de enquête alleen de antwoorden van iedereen op drie van de vijfhonderd vragen wil zien, is dat een heel eenvoudige SQL-query. U kunt een trapsgewijze verwijdering instellen om automatisch antwoorden en vragen te verwijderen wanneer een enquête wordt verwijderd. Het genereren van statistieken zal ook veel gemakkelijker zijn met dit schema.
Hier is een licht gewijzigde versie van het door u verstrekte schema. Ik neem aan dat je kunt achterhalen welke gegevenstypen waar naartoe gaan :-)
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