Lagring af dynamiske formulardata i DBMS, på udkig efter den optimale tilgang

Du har stået over for et almindeligt problem:At prøve at bruge noget statisk (database med foruddefineret struktur) til noget dynamisk (en masse individuelle datasæt, som kun har én ting til fælles:de kommer fra formularer). Det, du ønsker, er gørligt med databaser, men det ville være betydeligt nemmere at undvære, men da jeg antager, at du virkelig ønsker at bruge en database til dette, er det her, jeg ville gøre:

• Du har et document (eller spørgeskema ) som indeholder flere questions . Disse er begge generiske nok og kræver deres egne tabeller, ligesom du har gjort indtil videre.
• Hvert spørgsmål har en type som definerer, hvilken slags spørgsmål det er (multiple select, freeform, select one... ) og spørgsmålet har selvfølgelig også options . Så det er to borde mere. Begrundelsen her er, at afkobling af disse fra det faktiske spørgsmål tillader, at der eksisterer et vist abstraktionsniveau, og dine forespørgsler vil stadig være noget enkle, selvom de muligvis er langvarige.

Så hvert dokument har 1..n til spørgsmål, hvert spørgsmål har 1 type og 1..n muligheder. Springer lidt over, her er hvad jeg tænker på med linktabeller osv.

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

Denne form for design tillader flere ting:

• Spørgsmål i sig selv kan genbruges, meget praktisk, hvis du laver en generisk "besvar disse x tilfældige spørgsmål fra en pulje af y spørgsmål ".
• Nye typer kan nemt tilføjes uden at ødelægge eksisterende.
• Du kan altid navigere gennem strukturen ganske let, f.eks. "Hvad var navnet på dokumentet for dette enkelt spørgsmålssvar, jeg har? " eller "hvor mange mennesker har svaret forkert på dette ene spørgsmål?"
• Fordi typer er adskilt, kan du oprette en (web)brugergrænseflade, som nemt afspejler tilstanden i databasen - endnu bedre, hvis typen ændres, behøver du måske slet ikke at røre ved din brugergrænsefladekode.
>
• Da hver mulig mulighed for et spørgsmål er sin egen række i QuestionOptions tabel, kan du meget nemt få den faktiske værdi.

Det åbenlyse problem med dette er, at det kræver ret stram kobling mellem bordene for integritet og det vil være en smerte at komme til at køre ordentligt i starten. Også siden value i QuestionOptions er varchar, skal du være i stand til at parse ting meget, og du vil måske endda introducere et andet felt til konverteringstip.

Håber dette hjælper, selvom du slet ikke ville være enig i min løsning.