Ukládání dynamických dat formuláře v DBMS, hledání optimálního přístupu

Čelili jste běžnému problému:Pokuste se použít něco statického (databáze s předdefinovanou strukturou) pro něco dynamického (hromada jednotlivých datových sad, které mají pouze jednu věc společnou:pocházejí z formulářů). To, co chcete, je proveditelné s databázemi, ale bylo by podstatně jednodušší se bez nich obejít, ale protože předpokládám, že k tomu opravdu chcete použít databázi, udělal bych toto:

• Máte document (nebo dotazník ), který obsahuje více questions . Oba jsou dostatečně obecné a vyžadují své vlastní tabulky, stejně jako jste to dělali doposud.
• Každá otázka má type která definuje, o jaký druh otázky se jedná (multiple select, freeform, select one... ) a otázka má samozřejmě také options . Takže o dvě tabulky více. Důvodem je, že jejich oddělení od skutečné otázky umožňuje určitou úroveň abstrakce a vaše dotazy budou stále poněkud jednoduché, i když možná looooo dlouhé.

Každý dokument má tedy 1..n až otázek, každá otázka má 1 typ a 1..n možností. Trochu přeskakuji, tady je to, co mám na mysli s tabulkami odkazů atd.

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

Tento druh designu umožňuje několik věcí:

• Samotné otázky jsou opakovaně použitelné, velmi užitečné, pokud vytváříte obecný „odpovězte na těchto x náhodných otázek ze souboru y otázek ".
• Nové typy lze snadno přidávat, aniž by došlo k porušení stávajících.
• Vždy můžete snadno procházet strukturou, například „Jak se jmenoval dokument s touto jedinou odpovědí na otázku, kterou mám? “ nebo „kolik lidí odpovědělo nesprávně na tuto jednu otázku?“
• Protože jsou typy odděleny, můžete snadno vytvořit (webové) uživatelské rozhraní, které odráží stav v databázi – ještě lépe, pokud se typ změní, nemusíte se kódu uživatelského rozhraní vůbec dotknout.
• Protože každá možná možnost pro otázku má svůj vlastní řádek v QuestionOptions tabulky, skutečnou hodnotu získáte velmi snadno.

Zřejmý problém s tím je, že vyžaduje docela přísné propojení mezi tabulkami pro integritu a bude těžké se na začátku pořádně rozběhnout. Také od value v QuestionOptions je varchar, musíte být schopni spoustu věcí analyzovat a možná budete chtít zavést další pole pro tipy na převod.

Doufám, že to pomůže, i když byste s mým řešením vůbec nesouhlasili.