Stockage des données de formulaire dynamique dans le SGBD, recherche de l'approche optimale

Vous avez rencontré un problème courant :essayer d'utiliser quelque chose de statique (base de données avec une structure prédéfinie) pour quelque chose de dynamique (ensemble d'ensembles de données individuels qui n'ont qu'un point commun :ils proviennent de formulaires). Ce que vous voulez est faisable avec des bases de données, mais il serait beaucoup plus facile de s'en passer, mais comme je suppose que vous voulez vraiment utiliser une base de données pour cela, voici ce que je ferais :

• Vous avez un document (ou questionnaire ) qui contient plusieurs questions . Ces deux éléments sont assez génériques et nécessitent leurs propres tables, comme vous l'avez fait jusqu'à présent.
• Chaque question a un type qui définit de quel type de question il s'agit (sélection multiple, forme libre, en sélectionner un... ) et bien sûr la question a aussi des options . Cela fait donc deux tables de plus. Le raisonnement ici est que le fait de les découpler de la question réelle permet un certain niveau d'abstraction et que vos requêtes seront toujours assez simples, bien que peut-être looooooongs.

Ainsi, chaque document a 1..n questions, chaque question a 1 type et 1..n options. En sautant un peu, voici ce à quoi je pense avec les tables de liens, 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

Ce type de conception permet plusieurs choses :

• Les questions elles-mêmes sont réutilisables, très pratiques si vous faites un générique "répondez à ces x questions aléatoires à partir d'un pool de y questions ".
• De nouveaux types peuvent être ajoutés facilement sans casser ceux qui existent déjà.
• Vous pouvez toujours naviguer dans la structure assez facilement, par exemple "Quel était le nom du document pour cette réponse à une seule question ? " ou "combien de personnes ont répondu de manière incorrecte à cette seule question ?"
• Parce que les types sont séparés, vous pouvez créer une interface utilisateur (Web) qui reflète facilement l'état de la base de données. Mieux encore, si le type change, vous n'aurez peut-être même pas besoin de toucher à votre code d'interface utilisateur.
• Puisque chaque option possible pour une question est sa propre ligne dans le QuestionOptions tableau, vous pouvez obtenir la valeur réelle très facilement.

Le problème évident avec cela est qu'il nécessite un couplage assez strict entre les tables pour l'intégrité et qu'il sera difficile de fonctionner correctement au démarrage. Aussi depuis value dans les QuestionOptions est varchar, vous devez être capable d'analyser beaucoup de choses et vous voudrez peut-être même introduire un autre champ pour les conseils de conversion.

J'espère que cela vous aidera même si vous n'êtes pas du tout d'accord avec ma solution.