Almacenamiento de datos de formularios dinámicos en DBMS, buscando el enfoque óptimo

Se ha enfrentado a un problema común:tratar de usar algo estático (base de datos con estructura predefinida) para algo dinámico (conjunto de conjuntos de datos individuales que solo tienen una cosa en común:provienen de formularios). Lo que quieres es factible con bases de datos, pero sería mucho más fácil prescindir de ella; sin embargo, dado que asumo que realmente desea utilizar una base de datos para esto, esto es lo que haría:

• Tienes un document (o cuestionario ) que contiene múltiples questions . Ambos son lo suficientemente genéricos y requieren sus propias tablas, tal como lo ha hecho hasta ahora.
• Cada pregunta tiene un type que define qué tipo de pregunta es (selección múltiple, forma libre, seleccione una... ) y, por supuesto, la pregunta también tiene options . Así que son dos mesas más. El razonamiento aquí es que desacoplarlos de la pregunta real permite que exista cierto nivel de abstracción y sus consultas seguirán siendo algo simples, aunque posiblemente laaaaargas.

Entonces, cada documento tiene 1..n preguntas, cada pregunta tiene 1 tipo y 1..n opciones. Saltándome un poco, esto es lo que estoy pensando con las tablas de enlaces, etc.

Document
    bigint id
DocumentQuestions
    bigint document_id
    bigint question_id
Question
    bigint id
    varchar question
QuestionType
    bigint question_id
    bigint type_id
Type [pre-filled table with id:type pairs, such as 1=freeform, 2=select one etc.]
QuestionOptions
    bigint id
    bigint question_id
    varchar description
    varchar value

Answers
    bigint id
    bigint document_id
    [etc. such as user_id]
QuestionAnswers
    bigint answer_id
    bigint question_id
    bigint questionoptions_id

Este tipo de diseño permite varias cosas:

• Las preguntas en sí mismas son reutilizables, muy útiles si está haciendo un genérico "responda estas x preguntas aleatorias de un grupo de y preguntas ".
• Se pueden agregar nuevos tipos fácilmente sin romper los existentes.
• Siempre puede navegar a través de la estructura con bastante facilidad, por ejemplo, "¿Cuál era el nombre del documento para esta única pregunta que tengo? " o "¿cuántas personas han respondido incorrectamente a esta pregunta?"
• Debido a que los tipos están separados, puede crear una interfaz de usuario (web) que refleje fácilmente el estado en la base de datos; mejor aún, si el tipo cambia, es posible que ni siquiera tenga que tocar su código de interfaz de usuario.
• Dado que cada posible opción para una pregunta es su propia fila en QuestionOptions tabla, puede obtener el valor real muy fácilmente.

El problema obvio con esto es que requiere un acoplamiento bastante estricto entre las tablas para la integridad y será un dolor de cabeza para que funcione correctamente al principio. También desde value en las QuestionOptions es varchar, debe poder analizar muchas cosas e incluso es posible que desee introducir otro campo para sugerencias de conversión.

Espero que esto ayude aunque no estés de acuerdo con mi solución en absoluto.