¿Qué tablas y relaciones de bases de datos mysql soportarían una encuesta de preguntas y respuestas con preguntas condicionales? [cerrado]
Estoy trabajando en un sistema de encuestas bastante simple en este momento. El esquema de la base de datos va a ser simple: una tabla Survey, en una relación de uno a muchos con la tabla Question, que está en una relación de uno a muchos con la tabla Answer y con la tabla PossibleAnswers.
Recientemente el cliente se dio cuenta de que quiere la capacidad de mostrar ciertas preguntas solo a personas que dieron una respuesta particular a alguna pregunta anterior (por ejemplo. ¿Compra cigarrillos?{[11] } sería seguido por ¿Cuál es su ¿marca de cigarrillos favorita?, no tiene sentido hacer la segunda pregunta a un no fumador).
Ahora empecé a preguntarme cuál sería la mejor manera de implementar estas preguntas condicionales en términos de mi esquema de base de datos? If question A has 2 possible answers: A and B, and question B should only appear to a user if the answer was A?
Editar: Lo que estoy buscando es una manera de almacenar esa información sobre los requisitos en una base de datos. El tratamiento de los datos probablemente se hará en el lado de la aplicación, ya que mis habilidades SQL apestan;)
4 answers
Diseño de la Base de Datos de Encuestas
Última actualización: 3/5/2015
Archivos de diagrama y SQL ahora disponibles en https://github.com/durrantm/survey
Si utilizas esta respuesta (superior) o cualquier elemento, ¡añade comentarios sobre las mejoras !!!
Este es un verdadero clásico, hecho por miles. Siempre parece "bastante simple" para empezar, pero para ser bueno en realidad es bastante complejo. Para hacer esto en Rails usaría el modelo que se muestra en el diagrama adjunto. Estoy seguro de que parece mucho más complicado para algunos, pero una vez que has construido algunos de estos, a lo largo de los años, te das cuenta de que la mayoría de las decisiones de diseño son patrones muy clásicos, mejor abordados por una estructura de datos flexible y dinámica al principio.
Más detalles a continuación:
Detalles de los cuadros clave
Respuestas
La tabla respuestas es crítica ya que captura las respuestas reales de los usuarios. Notarás que las respuestas enlazan a question_options, no preguntas. Esto es intencional.
Tipos de entrada
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 un "incluir?"opción o alguna de esas combinaciones. Etiquetar las dos preguntas en la vista de los usuarios como una, pero internamente tienen dos preguntas, una para los diales de radio, una para la casilla de verificación. La casilla de verificación tendrá un grupo de 1 en este caso.
Grupos de opciones
Option_groups y option_choices permiten construir 'común' de los grupos. Un ejemplo, en una aplicación de bienes raíces podría haber la pregunta ' ¿Qué 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' lo anterior rangos, para que se usen las mismas option_group y options.
Units_of_measure
Units_of_measure es como suena. Ya sean pulgadas, tazas, píxeles, ladrillos o lo que sea, puedes definirlo una vez aquí.
Para su información: Aunque de naturaleza genérica, se puede crear una aplicación encima de esto, y este esquema es muy adecuado para el framework Ruby On Rails con convenciones como "id" para la clave primaria para cada tabla. También las relaciones son todas simples one_to_many es sin necesidad de many_to_many o has_many a través. Probablemente agregaría has_many: through y / o: delegates para obtener cosas como survey_name de una respuesta individual fácilmente sin.multiple.encadenar.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-05-13 10:51:17
También podría pensar en reglas complejas, y tener un campo de condición basado en cadenas en su tabla de preguntas, aceptando/analizando cualquiera de estas:
- A (1) = 3
- ((A (1) = 3) y (A(2)=4) )
- a(3)>2
- (a(3)=1) y (A(17)!= 2) y C(1)
Donde A(x)=y significa "Respuesta de la pregunta x es y" y C(x) significa la condición de la pregunta x (por defecto es true)...
Las preguntas tienen un campo de orden, y las revisarías una por una, saltando preguntas donde la condición es FALSA.
Esto debería permitir encuestas de cualquier complejidad que desee, su GUI podría crearlas automáticamente en "Modo simple" y permitir un "Modo avanzado" donde un usuario puede ingresar las ecuaciones directamente.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-02-14 00:35:36
Una forma es agregar una tabla 'requisitos de pregunta' con campos:
- question_id (enlace a " which brand?"pregunta)
- required_question_id (enlace a " ¿fumas?"pregunta)
- required_answer_id (enlace a la respuesta "sí")
En la aplicación, marque esta tabla antes de plantear una pregunta determinada. Con una tabla separada, es fácil agregar respuestas requeridas(agregar otra fila para la respuesta" a veces", etc...)
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-02-12 11:29:13
Personalmente, en este caso, usaría la estructura que describiste y usaría la base de datos como un mecanismo de almacenamiento tonto. Soy fan de poner estas restricciones complejas y dependientes en la capa de aplicación.
Creo que la única manera de hacer cumplir estas restricciones sin construir nuevas tablas para cada pregunta con claves foráneas para otras, es usar el material de T-SQL u otros mecanismos específicos del proveedor para construir disparadores de base de datos para hacer cumplir estas restricciones.
En una solicitud nivel tienes muchas más posibilidades y es más fácil de portar, así que preferiría esa opción.
Espero que esto te ayude a encontrar una estrategia para tu aplicación.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-02-12 11:36:12