Dynamische formuliergegevens opslaan in DBMS, op zoek naar de optimale aanpak

Je hebt te maken gehad met een veelvoorkomend probleem:proberen iets statisch (database met vooraf gedefinieerde structuur) te gebruiken voor iets dynamischs (een stel individuele datasets die maar één ding gemeen hebben:ze komen uit formulieren). Wat je wilt is uitvoerbaar met databases, maar het zou aanzienlijk gemakkelijker zijn om zonder te doen, maar aangezien ik aanneem dat je hier echt een database voor wilt gebruiken, zou ik het volgende doen:

• Je hebt een document (of vragenlijst ) die meerdere questions . bevat . Deze zijn allebei generiek genoeg en hebben hun eigen tabellen nodig, net zoals je tot nu toe hebt gedaan.
• Elke vraag heeft een type die definieert wat voor soort vraag het is (meerdere selectie, vrije vorm, één selecteren... ) en natuurlijk heeft de vraag ook options . Dat zijn dus twee tafels meer. De redenering hier is dat het loskoppelen van deze van de eigenlijke vraag een bepaald abstractieniveau mogelijk maakt en dat uw vragen nog steeds enigszins eenvoudig zullen zijn, hoewel mogelijk lang.

Elk document heeft dus 1..n tot vragen, elke vraag heeft 1 type en 1..n opties. Even overslaan, dit is waar ik aan denk met linktabellen enz.

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

Dit soort ontwerp laat verschillende dingen toe:

• Vragen zelf zijn herbruikbaar, erg handig als je een generieke "beantwoord deze x willekeurige vragen uit een pool van y vragen maakt ".
• Nieuwe typen kunnen eenvoudig worden toegevoegd zonder bestaande te breken.
• Je kunt altijd vrij gemakkelijk door de structuur navigeren, bijvoorbeeld "Wat was de naam van het document voor deze enkele vraag die ik heb beantwoord? " of "hoeveel mensen hebben deze ene vraag fout beantwoord?"
• Omdat typen gescheiden zijn, kun je een (web) UI maken die de status in de database eenvoudig weergeeft - beter nog, als het type verandert, hoef je misschien niet eens je UI-code aan te raken.
>
• Aangezien elke mogelijke optie voor een vraag zijn eigen rij is in de QuestionOptions tabel, kunt u de werkelijke waarde heel gemakkelijk krijgen.

Het voor de hand liggende probleem hiermee is dat het een vrij strikte koppeling tussen de tabellen vereist voor integriteit en lastig zal zijn om in het begin goed te werken. Ook sinds value in de QuestionOptions is varchar, moet je veel dingen kunnen ontleden en misschien wil je zelfs een ander veld voor conversiehints introduceren.

Ik hoop dat dit helpt, ook al ben je het helemaal niet eens met mijn oplossing.