Su primer esquema es la mejor opción de los dos. En este punto, no debe preocuparse por los problemas de rendimiento. Preocúpate por hacer un buen diseño, flexible, extensible. Hay todo tipo de trucos que puede hacer más tarde para almacenar datos en caché y hacer consultas más rápidas. Usar un esquema de base de datos menos flexible para resolver un problema de rendimiento que puede que ni siquiera se materialice es una mala decisión.
Además, muchos (quizás la mayoría) de los resultados de las encuestas solo son vistos periódicamente y por una pequeña cantidad de personas (organizadores de eventos, administradores, etc.), por lo que no estará consultando constantemente la base de datos para obtener todos los resultados. E incluso si lo fuera, el rendimiento estará bien. De todos modos, probablemente paginarías los resultados de alguna manera.
El primer esquema es mucho más flexible. Puede, de forma predeterminada, incluir preguntas como el nombre y la dirección, pero para las encuestas anónimas, simplemente no puede crearlas. Si el creador de la encuesta solo quiere ver las respuestas de todos a tres preguntas de quinientas, esa es una consulta SQL realmente simple. Puede configurar una eliminación en cascada para eliminar automáticamente las respuestas y preguntas cuando se elimina una encuesta. Generar estadísticas también será mucho más fácil con este esquema.
Aquí hay una versión ligeramente modificada del esquema que proporcionó. Supongo que puede averiguar qué tipos de datos van a dónde :-)
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
