Diseño de base de datos para una encuesta [cerrado]

Necesito crear una encuesta donde las respuestas se almacenan en una base de datos. Me pregunto cuál sería la mejor manera de implementar esto en la base de datos, específicamente las tablas requeridas. La encuesta contiene diferentes tipos de preguntas. Por ejemplo: campos de texto para comentarios, preguntas de opción múltiple y posiblemente preguntas que podrían contener más de una respuesta (es decir, marque todas las que correspondan).

Se me ocurrieron dos posibles soluciones:

1. Cree una tabla gigante que contenga las respuestas para cada envío de encuesta. Cada columna correspondería a una respuesta de la encuesta. es decir, SurveyID, Answer1, Answer2, Answer3

   No creo que esta sea la mejor manera, ya que hay muchas preguntas en esta encuesta y no parece muy flexible si la encuesta va a cambiar.

2. La otra cosa que pensé fue crear una tabla de preguntas y una tabla de respuestas. La tabla de preguntas contendría todas las preguntas para la encuesta. La tabla de respuestas contendría respuestas individuales de la encuesta, cada fila vinculada a una pregunta.

   Un simple ejemplo:

   tblSurvey : SurveyID

   tblQuestion : QuestionID, SurveyID , QuestionType, Question

   tblAnswer : AnswerID, ID de usuario , IdPregunta , respuesta

   tblUser : UserID , UserName

   Mi problema con esto es que podría haber toneladas de respuestas que harían que la tabla de respuestas sea bastante grande. No estoy seguro de que sea tan bueno cuando se trata de rendimiento.

Agradecería cualquier idea y sugerencia.

Creo que su modelo # 2 está bien, sin embargo, puede echar un vistazo al modelo más complejo que almacena preguntas y respuestas prefabricadas (respuestas ofrecidas) y permite que se reutilicen en diferentes encuestas.

- Una encuesta puede tener muchas preguntas; Una pregunta puede ser (re) utilizada en muchas encuestas.
- Se puede ofrecer una respuesta (prefabricada) para muchas preguntas. Una pregunta puede tener muchas respuestas ofrecidas. Una pregunta puede tener diferentes respuestas ofrecidas en diferentes encuestas. Se puede ofrecer una respuesta a diferentes preguntas en diferentes encuestas. Hay una respuesta predeterminada "Otro", si una persona elige otra, su respuesta se registra en Answer.OtherText.
- Una persona puede participar en muchas encuestas, una persona puede responder preguntas específicas en una encuesta solo una vez.

Mi diseño se muestra a continuación.

El último script de creación está en https://gist.github.com/durrantm/1e618164fd4acf91e372

El script y el archivo mysql workbench.mwb también están disponibles en
https://github.com/durrantm/survey

Definitivamente la opción # 2, también creo que podría tener una supervisión en el esquema actual, es posible que desee otra tabla:

+-----------+
| tblSurvey |
|-----------|
| SurveyId  |
+-----------+

+--------------+
| tblQuestion  |
|--------------|
| QuestionID   |
| SurveyID     |
| QuestionType |
| Question     |
+--------------+

+--------------+
| tblAnswer    |
|--------------|
| AnswerID     |
| QuestionID   |
| Answer       |
+--------------+

+------------------+
| tblUsersAnswer   |
|------------------|
| UserAnswerID     |
| AnswerID         |
| UserID           |
| Response         |
+------------------+

+-----------+
| tblUser   |
|-----------|
| UserID    |
| UserName  |
+-----------+

Es probable que cada pregunta tenga un número establecido de respuestas entre las que el usuario puede seleccionar, luego las respuestas reales se rastrearán en otra tabla.

Las bases de datos están diseñadas para almacenar una gran cantidad de datos, y la mayoría escalan muy bien. No hay necesidad real de usar una forma normal menor simplemente para ahorrar espacio.

Como regla general, modificar el esquema basado en algo que un usuario podría cambiar (como agregar una pregunta a una encuesta) debería considerarse bastante maloliente. Hay casos en los que puede ser apropiado, particularmente cuando se trata de grandes cantidades de datos, pero sepa en qué se está metiendo antes de sumergirse. Tener solo una tabla de "respuestas" para cada encuesta significa que agregar o eliminar preguntas es potencialmente muy costoso , y es muy difícil hacer análisis de una manera agnóstica de preguntas.

Creo que su segundo enfoque es el mejor, pero si está seguro de que va a tener muchos problemas de escala, una cosa que me ha funcionado en el pasado es un enfoque híbrido:

1. Cree tablas de respuestas detalladas para almacenar las respuestas por pregunta como ha descrito en 2. Estos datos generalmente no se consultarían directamente desde su aplicación, sino que se utilizarían para generar datos de resumen para las tablas de informes. Probablemente también desee implementar alguna forma de archivar o eliminar estos datos.
2. También cree la tabla de respuestas de 1 si es necesario. Esto se puede usar siempre que los usuarios quieran ver una tabla simple de resultados.
3. Para cualquier análisis que deba realizarse con fines informativos, programe trabajos para crear datos de resumen adicionales basados ​​en los datos de 1.

Esto es absolutamente mucho más trabajo para implementar, por lo que realmente no lo recomendaría a menos que sepa con certeza que esta tabla tendrá problemas de escala masiva.

El segundo enfoque es el mejor.

Si desea normalizarlo aún más, puede crear una tabla para los tipos de preguntas

Las cosas simples que hacer son:

• Coloque la base de datos e inicie sesión en su propio disco, no todos en C por defecto
• Cree la base de datos tan grande como sea necesario para que no tenga pausas mientras la base de datos crece

Hemos tenido tablas de registro en la tabla de SQL Server con 10 de millones de filas.

No 2 se ve bien.

Para una tabla con solo 4 columnas no debería ser un problema, incluso con unos pocos millones de filas. Por supuesto, esto puede depender de qué base de datos esté utilizando. Si es algo así como SQL Server, entonces no sería un problema.

Probablemente desee crear un índice en el campo QuestionID, en la tabla tblAnswer.

Por supuesto, debe especificar qué base de datos está utilizando, así como los volúmenes estimados.

Parece bastante completo para una encuesta simple. No olvide agregar una tabla para "valores abiertos", donde un cliente puede dar su opinión a través de un cuadro de texto. Vincula esa tabla con una clave externa a tu respuesta y coloca índices en todas tus columnas relacionales para el rendimiento.

El número 2 es correcto. Use el diseño correcto hasta y a menos que detecte un problema de rendimiento. La mayoría de los RDBMS no tendrán problemas con una tabla estrecha pero muy larga.

Tener una gran tabla de respuestas, en sí misma, no es un problema. Mientras los índices y las restricciones estén bien definidos, debería estar bien. Tu segundo esquema me parece bien.

Dado el índice adecuado, su segunda solución está normalizada y es buena para un sistema de base de datos relacional tradicional.

No sé qué tan grande es enorme, pero debería contener sin problemas un par de millones de respuestas.

Puede elegir almacenar todo el formulario como una cadena JSON.

No estoy seguro acerca de su requisito, pero este enfoque funcionaría en algunas circunstancias.