Solución:
Esquema de base de datos de encuestas.
Este es un verdadero clásico, hecho por miles. Al principio, siempre parecen “bastante simples”, pero para ser buenos, en realidad son bastante complejos. Para hacer esto en Rails, usaría el modelo que se muestra en el diagrama adjunto. Estoy seguro de que parece demasiado complicado para algunos, pero una vez que haya construido algunos de estos, a lo largo de los años, se dará cuenta de que la mayoría de las decisiones de diseño son patrones muy clásicos, mejor abordados por una estructura de datos dinámica y flexible en el comienzo.
Más detalles a continuación:
Detalles de la tabla para tablas clave
respuestas
los respuestas La tabla es fundamental ya que captura las respuestas reales de los usuarios. Notarás que las respuestas enlazan a question_options, no preguntas. Esto es intencional.
input_types
input_types son los tipos de preguntas. Cada pregunta solo puede ser de 1 tipo, por ejemplo, todos los diales de radio, todos los campos de texto, etc. Utilice preguntas adicionales para cuando haya (digamos) 5 diales de radio y 1 casilla de verificación para “incluir?” opción o alguna combinación similar. Etiquete las dos preguntas en la vista de los usuarios como una, pero internamente tienen dos preguntas, una para los diales de radio y otra para la casilla de verificación. La casilla de verificación tendrá un grupo de 1 en este caso.
option_groups
option_groups y option_choices le permite construir grupos “comunes”. Un ejemplo, en una solicitud de bienes raíces podría haber la pregunta “¿Qué antigüedad tiene la propiedad?”. Las respuestas pueden ser deseadas en los rangos: 1-5 6-10 10-25 25-100 100+
Entonces, por ejemplo, si hay una pregunta sobre la antigüedad de la propiedad contigua, entonces la encuesta querrá ‘reutilizar’ los rangos anteriores, de modo que se usen el mismo grupo de opciones y opciones.
unidades de medida
unidades de medida es como suena. Ya sean pulgadas, tazas, píxeles, ladrillos o lo que sea, puede definirlo una vez aquí.
Para su información: aunque es de naturaleza genérica, se puede crear una aplicación además de esto, y este esquema se adapta bien al Ruby on Rails marco con convenciones como “id” para la clave principal de cada tabla. Además, las relaciones son todas simples one_to_many sin necesidad de many_to_many o has_many. Probablemente agregaría has_many: throughs y / o: delegates para obtener cosas como survey_name de una respuesta individual fácilmente sin múltiples cadenas.
Necesita hacer una distinción entre el posible respuestas y el seleccionado respuestas.
los Option la mesa debe ser de dos mesas. los Option la tabla debe ser de 1: M a Question y debe incluir las posibles respuestas a esa pregunta.
Entonces necesitas crear una nueva entidad de intersección, llámala Selected_Option que se encuentra entre User y Option.
Si su pregunta le da al usuario la oportunidad de completar un valor como respuesta (es decir, “OTRO: …”), este valor se almacenaría en el Selected_Option mesa. De lo contrario, el valor elegido por el usuario sería el valor encontrado en Option.
EDITAR:
Basado en la aclaración de los requisitos de OP: Lo que necesita no es como un modelo de cuestionario típico de las siguientes maneras:
- Todas sus preguntas tienen el mismo conjunto de respuestas (columnas)
- Algunas de sus respuestas (columnas) están agrupadas.
- Los bloques de preguntas se agrupan.
Tomando la instantánea de su formulario como guía, he dividido los elementos de su formulario en entidades que he codificado por colores:
Esto podría adaptarse al siguiente ERD lógico:
Tenga en cuenta que he codificado por colores las entidades en el ERD para que se correspondan con la instantánea de su formulario de muestra para mostrar la correlación.
Uno de los supuestos en este modelo es que cada bloque tiene solo un conjunto de preguntas (es decir, una QUESTION_GROUP) que corresponde a la columna de la izquierda del bloque. Esta es una suposición un poco simplificadora.
Eche un vistazo a esta idea general:
(Solo los campos más esenciales se incluyen en el modelo anterior, por brevedad).
Este modelo tiene las siguientes características:
- Una sola pregunta se puede compartir entre varias encuestas (y una sola encuesta, por supuesto, puede contener varias preguntas). SURVEY_QUESTION es la tabla de “enlace” que implementa esta relación M: N.
- El orden de las preguntas de la encuesta lo determina SURVEY_QUESTION.QUESTION_NO. Dado que {SURVEY_NO, QUESTION_NO} es una clave (alternativa), denotada por
U1en el diagrama anterior, no hay dos preguntas que puedan ocupar el mismo “espacio” en la misma encuesta. Diferentes encuestas pueden tener las mismas preguntas en un orden diferente. - Cada pregunta tiene una serie de posibles respuestas u “opciones”. El orden visual de las opciones está determinado por OPTION.OPTION_NO, y dado que está en el PK, no hay dos opciones que ocupen el mismo “espacio” en la misma pregunta.
- Diferentes usuarios pueden proporcionar diferentes respuestas a la misma pregunta (y, por supuesto, un usuario puede responder varias preguntas). Esta relación M: N se implementa a través de la tabla “enlace” RESPUESTA.
- Un usuario responde a la pregunta eligiendo como máximo una de sus opciones. Esto está asegurado por Excluyendo el OPTION_NO del PK de ANSWER. Si desea permitir que el usuario seleccione varias opciones, incluya OPTION_NO en el PK.
No hay nada en este modelo de datos que obligue al usuario a responder todos las preguntas: esto es algo que deberá hacer en el nivel de la aplicación. No obstante, este modelo debería ser un buen comienzo para lo que necesita hacer …