Gestión de valores fijos y definidos por el usuario

Gestión de valores fijos y definidos por el usuario

Estoy diseñando la base de datos para una aplicación en la que al usuario se le presentan preguntas y debe responderlas. Piense en ello como un cuestionario o como un juego de preguntas, el concepto se aplica a ambos. Planeo tener:

  • una tabla con las preguntas
  • una tabla con las posibles respuestas, cada una de ellas vinculada a la pregunta a la que pertenece con una clave externa (simplifiquemos las cosas y supongamos que es una relación 1:muchos, donde las respuestas no se pueden compartir entre preguntas)
  • una tabla con las respuestas que proporcionaron los usuarios (con claves externas a la pregunta, la respuesta y el ID de usuario)

Dado que muchas de las preguntas serán casos comunes, como sí/no, decidí especificar una enumeración de "tipo de pregunta" para cada pregunta. Si la aplicación ve una pregunta de sí/no, por ejemplo, significa que no hay respuestas en la base de datos, y la aplicación agregará automáticamente las dos respuestas, "Sí" y "No". Esto me ahorra cientos o miles de filas inútiles en la tabla de respuestas.

Sin embargo, no estoy seguro de cómo debo definir la tabla para registrar las respuestas de los usuarios. Sin los tipos especiales de preguntas, simplemente registraría el ID de la pregunta, el ID de la respuesta y el ID del usuario, lo que significa que "el usuario X respondió Y a la pregunta Z". Sin embargo, las preguntas de "sí/no" no tendrían una respuesta coincidente en la tabla, por lo que no puedo usar el ID de respuesta.

Incluso hacer que las respuestas se puedan compartir entre preguntas (estableciendo una relación de muchos a muchos entre preguntas y respuestas) no es una buena solución. Claro, me permitiría definir "Sí" y "No" como respuestas normales, pero las aplicaciones deben tener en cuenta que una pregunta de "sí/no" usa las respuestas (digamos) 7 y 8, o, al crear un "sí/ no" las respuestas a las preguntas 7 y 8 deben estar vinculadas a esa pregunta. Pero esto significa que las ID de estas respuestas "especiales" deben estar codificadas en otro lugar. Además, esto no escalaría bien si agregara más tipos especiales de preguntas en el futuro.

¿Cómo debo proceder? Idealmente, necesito almacenar en cada fila de mi tabla de "respuestas de usuario" un valor fijo o una clave externa para la tabla de respuestas. ¿Hay una mejor solución que usar dos columnas, una de las cuales es NULL?

Estoy usando SQL Server, si eso importa.

Mostrar la mejor respuesta

Según su descripción, creo que seguiría la ruta de agregar otra columna a la tabla y hacer que la columna FK admita valores nulos.

Probablemente solo tenga unas pocas opciones para esas preguntas especiales, por lo que un tipo de datos TINYINT anulable lo reduciría, y es solo 1 byte adicional para su fila de respuesta. Si esta columna adicional aumenta el número de columnas a más de un múltiplo de ocho, digamos que pasa de 8 a 9 o de 16 a 17, entonces paga otro byte adicional por el crecimiento del mapa de bits nulo. Pero son 2 bytes adicionales por fila en el peor de los casos.

Gran análisis, especialmente por el impacto en el espacio en disco. Sin embargo, los códigos de respuesta especiales y su asociación con tipos de preguntas especiales tendrían que codificarse en la aplicación o definirse en tablas adicionales.

Sí, ese es otro asunto y tenía la impresión de que estarían codificados, pero puede seguir la ruta de tener una tabla "SpecialPossibleAnswers" para una extensibilidad más fácil. Pero entonces no está evitando exactamente un acceso a la base de datos para cada pregunta/respuesta.