Conception de la base de données du questionnaire - quelle est la meilleure solution?

J'ai UNE longue page html, plusieurs séries de questions divisées en petites sections (environ 15 sous-sections sur une page), le total des questions est d'environ 100 questions: varie selon la saisie, choix multiple, cases à cocher, boutons radio, zone de texte, et le téléchargement de fichiers. Une question peut contenir de nombreuses réponses obtenues à partir d'un groupe de cases à cocher, d'un groupe de listes de sélection, d'un groupe de sélections multiples, ou de toutes combinées en une seule réponse. J'ai pensé utiliser cette conception de base de données ci-dessous, mais j'ai découvert récemment que ce n'était pas la bonne approche après tout.

1. Un client ne peut avoir qu'une seule série de questions: un client pour 100 questions.
2. Pour l'ancienne approche, je ne garde pas la question dans la base de données, mais je l'assigne comme constante dans le codage PHP à la place. Le problème est que je dois comparer la question en PHP pour la synchroniser avec la réponse dans la base de données. Si une question avait été modifiée / supprimée / déplacée de PHP, je me perdrais définitivement pour la faire correspondre avec la réponse dans la base de données du questionnaire. Une meilleure solution?
3. Puis-je être en mesure de conserver plusieurs réponses obtenues à partir de plusieurs éléments sous forme dans un seul champ comme une seule réponse? Comment puis-je récupérer ce champ et l'afficher à nouveau pour que le client puisse le visualiser sur le formulaire?
4. Quelle option ci-dessous dois-je choisir?

OPTION 1: Ancienne approche (1 tableau)

TABLEAU: Questionnaire

• ID (PK)
• N ° de client
• Statut
• A1
• A2
• A3
• .
• .
• .
• A100

OPTION 2: Nouvelle approche (2 tableaux)

TABLE: Question

• QID (PK)
• Question (varchar)

TABLE: Réponse

• AID (PK)
• N ° de client
• QID (int)
• Réponse (varchar)

Ou OPTION 3?

Certainement, ne codez pas en dur votre questionnaire. Utilisez une base de données relationnelle ou des fichiers xml. Je propose les tableaux suivants

• Questionnaire: Description générale du questionnaire. Titre, nom de l'enquête, date de publication du questionnaire, version, etc.

• Section: Les sections d'un questionnaire sont constituées. Numéro de la section, titre de la section, description.

• Question: Les questions appartenant à une section. Numéro de la question, texte de la question, description, type de question (texte, choix multiple, etc.).

• Question_Choice: Les réponses possibles appartenant à une question correspondant aux cases à cocher, boutons radio, etc. Texte du choix, numéro du choix, commande.

• Respondent: Les personnes répondant aux questions. Données personnelles, numéro d'utilisateur.

• Interview: Entretiens ou tests ou enquêtes (selon la nature du questionnaire) appartenant à un répondant et à un questionnaire. Si un répondant peut toujours répondre à un seul questionnaire (ou si l'enquête est anonyme), ce tableau est obsolète et peut être fusionné avec le tableau Répondant. Date de l'entretien (ou date du test ou date de l'enquête), intervieweur (le cas échéant).

• Answer: Réponses appartenant à un entretien (ou répondant, voir ci-dessus) et à une question. Texte de réponse (pour les questions de type texte), choix (pour les boutons radio).

• Answer_Choice: Choix appartenant à une réponse et à une question_ choix lorsque plusieurs choix peuvent être vérifiés.

Il s'agit d'une approche très normalisée; cependant, vous pouvez décider de concaténer des choix dans une chaîne ou de les stocker en tant que modèle binaire ou de le simplifier d'une autre manière en fonction de vos besoins.

Vous avez besoin de quelques tables,

1 - Les questions (identifiant de la question, type d'entrée, visible, type de question, texte de la question, réponses attendues ....)

2 - Les réponses (identifiant de la question, identifiant de l'utilisateur, identifiant de l'activité, réponse ....)

3 - Les utilisateurs (identifiant, nom d'utilisateur ......)

4 - Un tableau pour contenir une activité de question / réponse (identifiant d'activité, données / temps, identifiant d'utilisateur)

Vous pouvez également souhaiter avoir un tableau qui spécifie les questions qui doivent être appliquées pour chaque activité - soit regroupées par utilisateur ou peut-être une collection de questions. Les clés étrangères / primaires seront les colonnes qui ont le même nom dans plusieurs tables et doivent être indexées.

Si vous utilisez cette structure, vous devriez pouvoir ajouter une question ou un utilisateur ou modifier une réponse sans avoir à modifier votre schéma ou votre code de présentation - assurez-vous que le code de présentation est créé dynamiquement au moment de l'exécution - il vous suffit d'ajouter un enregistrement au bon endroit.

Cette approche peut prendre plus de temps à développer initialement qu'une approche codée en dur, mais sera beaucoup plus simple à maintenir car vous n'aurez qu'à modifier les données pour changer le comportement.

(Un conseil, pour créer votre couche de présentation, vous aurez besoin d'une requête qui affiche les questions appropriées, puis parcourez cet ensemble de résultats et appelez une méthode pour rendre la question à l'écran, les méthodes à choisir étant appropriées à la présentation de cette question [zone de texte, groupe radio, etc.])