Diseño de la base de datos del cuestionario: ¿cuál es la mejor manera?

Tengo UNA página html larga, varios conjuntos de preguntas divididas en secciones pequeñas (aproximadamente 15 subsecciones en una página), el total de preguntas son aproximadamente 100 preguntas: varía de entrada, opción múltiple, casillas de verificación, botones de radio, área de texto, y carga de archivos. Una pregunta podría contener muchas respuestas que se obtuvieron del grupo de casillas de verificación, grupo de lista de selección, grupo de selección múltiple o todas ellas combinadas en una sola respuesta. Pensé que usaría este diseño de base de datos a continuación, pero descubrí últimamente que no es el buen enfoque después de todo.

1. Un cliente solo puede tener un conjunto de preguntas: un cliente por cada 100 preguntas.
2. Para el enfoque anterior, no mantengo preguntas en la base de datos, sino que las asigno como constantes en la codificación PHP. El problema es que tengo que comparar la pregunta en PHP para sincronizarla con la respuesta en la base de datos. Si una pregunta hubiera sido alterada / eliminada / movida de PHP, definitivamente me perdería para que coincida con la respuesta en la base de datos del cuestionario. Mejor solución?
3. ¿Podría mantener múltiples respuestas obtenidas de múltiples elementos en forma en un campo como una sola respuesta? ¿Cómo podría recuperar este campo y mostrarlo nuevamente para que el cliente lo vea en el formulario?
4. ¿Qué opción a continuación debo elegir?

OPCIÓN 1: Enfoque antiguo (1 tabla)

TABLA: Cuestionario

• ID (PK)
• Identificación del cliente
• Estado
• A1
• A2
• A3
• .
• .
• .
• A100

OPCIÓN 2: Nuevo enfoque (2 tablas)

TABLA: Pregunta

• QID (PK)
• Pregunta (varchar)

TABLA: Respuesta

• AYUDA (PK)
• Identificación del cliente
• QID (int)
• Respuesta (varchar)

O la OPCIÓN 3?

Definitivamente no codifique su cuestionario. Use una base de datos relacional o archivos xml. Propongo las siguientes tablas

• Questionnaire: Descripción general del cuestionario. Título, nombre de la encuesta, fecha de lanzamiento del cuestionario, versión, etc.

• Section: Las secciones de un cuestionario está compuesto. Número de la sección, título de la sección, descripción.

• Question: Las preguntas que pertenecen a una sección. Número de la pregunta, texto de la pregunta, descripción, tipo de pregunta (texto, opción múltiple, etc.).

• Question_Choice: Las posibles respuestas que pertenecen a una pregunta correspondiente a casillas de verificación individuales, botones de opción, etc. Texto de la elección, número de elección, orden.

• Respondent: Las personas que responden las preguntas. Datos personales, número de usuario.

• Interview: Entrevistas o pruebas o encuestas (dependiendo de la naturaleza del cuestionario) pertenecientes a un encuestado y un cuestionario. Si un encuestado siempre puede responder un solo cuestionario (o si la encuesta es anónima), esta tabla está obsoleta y se puede combinar con la tabla Respondent. Fecha de entrevista (o fecha de prueba o fecha de encuesta), entrevistador (si corresponde).

• Answer: Respuestas pertenecientes a una entrevista (o encuestado, ver arriba) y una pregunta. Texto de respuesta (para preguntas de tipo de texto), elección (para botones de opción).

• Answer_Choice: Opciones que pertenecen a una respuesta y una pregunta_ elección cuando se pueden verificar varias opciones.

Este es un enfoque muy normalizado; sin embargo, puede decidir concatenar las opciones en una cadena o almacenarlas como un patrón de bits o simplificarlas de alguna otra manera según sus necesidades.

Necesitas algunas mesas,

1 - Las preguntas (identificación de la pregunta, tipo de entrada, visible, tipo de pregunta, texto de la pregunta, respuestas esperadas ...)

2 - Las respuestas (ID de pregunta, ID de usuario, ID de actividad, respuesta ...)

3 - Los usuarios (identificación de usuario, nombre de usuario ......)

4 - Una tabla para guardar una actividad de preguntas / respuestas (id. De actividad, datos / hora, id. De usuario)

También es posible que desee tener una tabla que especifique las preguntas que deben aplicarse para cada actividad, ya sea agrupadas por usuario o tal vez una colección de preguntas. Las claves externas / primarias serán las columnas que tienen el mismo nombre en varias tablas y deben indexarse.

Si usa esta estructura, debería poder agregar una pregunta o usuario o cambiar una respuesta sin tener que cambiar su esquema o código de presentación; asegúrese de que el código de presentación se cree dinámicamente en el tiempo de ejecución; solo necesita agregar un registro en el lugar apropiado

Este enfoque puede tardar más en desarrollarse inicialmente que un enfoque codificado, pero será mucho más simple de mantener, ya que solo necesitará cambiar los datos para cambiar el comportamiento.

(Un consejo, para crear su capa de presentación, necesitará una consulta que muestre las preguntas apropiadas, luego recorra este conjunto de resultados y llame a un método para hacer preguntas en la pantalla, los métodos para elegir son apropiados para el presentación de esa pregunta [cuadro de texto, grupo de radio, etc.])