¿Es este un buen diseño de base de datos para una aplicación de prueba?

Answer 1

El mayor problema en su diseño hasta ahora parece ser el diseño de la relación de preguntas y respuestas.

• Si cada cuestionario tiene su propio tipo de respuestas, ¿por qué el número de opciones en la respuesta es estático?
• ¿Por qué se almacena la respuesta correcta con las opciones de respuesta?
• ¿Por qué no almacena las respuestas del examinado en lugar de solo el puntaje?

Personalmente, haría una tabla de respuestas que simplemente contenía una sola opción por registro.

Haga que la tabla de preguntas simplemente contenga las preguntas y cualquier tipo de metadatos sobre el tipo de pregunta y respuesta esperada.

Haga que haya una relación de muchos a muchos entre las respuestas y la pregunta, de esa manera las opciones pueden ser aleatorizadas.

Luego, haga otra tabla que contenga las respuestas reales en una relación de uno a muchos con la pregunta y de muchos a muchos con las opciones de respuesta. Con esta tabla puede al menos especificar una sola respuesta correcta, múltiples respuestas correctas, especificar un orden en el que se deben colocar las respuestas, incluso especificar puntuaciones parciales si seleccionan un par de ellas correctamente y especificar deducciones si ponen respuestas incorrectas.

Sin conocer las especificaciones reales de qué tipo de respuestas se esperan, es difícil decir qué más necesitaría especificar.

Podría ser más específico, pero no me gustaría hacer la tarea por ti.

Answer 2

La pregunta para mí es por qué eliges estructurar las respuestas que eres.

Pequeña crítica, pero una que me llamó la atención de inmediato: la forma en que actualmente estructura las respuestas, se asemeja a una relación 1: 1 en que un conjunto particular de respuestas es asociativo con una pregunta. Si tiene exactamente el mismo conjunto de respuestas para diferentes preguntas, bueno, esa no es una prueba que quiero responder 🙂

Mi mayor crítica es que me preocupa que la especificación de su problema incluya “tipo de respuestas”, lo que sugiere que es posible que tenga que ampliar el diseño para incluir preguntas que no sean de opción múltiple y diferentes tipos de respuestas. El esquema tal cual funciona para solo 4 preguntas de opción múltiple de forma libre. (Además, el campo de respuesta debería ser una ID en lugar de varchar, lo que apunta a normalizar las respuestas a su propia tabla)

Pero, en general, no soy tan adusto con el diseño como lo son algunos de los encuestados, y creo que puede crear una aplicación de cuestionario de opción múltiple limitada con el esquema. No es el esquema que usaría, no es súper eficiente, es rígido. Pero la mejor manera de tener una idea de qué esquema funciona y qué no funciona es implementarlos.

Answer 3

La respuesta es NO, probablemente debería usar algo como MongoDB, que obviamente es una solución mucho mejor para sus necesidades, ya que no tiene Schema.

Con la base de datos basada en documentos, puede evitar cosas como su escenario tbl_answer en el que debe definir estrictamente el número de respuestas que puede tener, así como otras limitaciones de diseño creadas por el diseño tabular.