Съхранение на динамични данни от формуляр в СУБД, търсене на оптимален подход

Сблъсквали сте се с често срещан проблем:опит да използвате нещо статично (база данни с предварително дефинирана структура) за нещо динамично (куп от отделни набори от данни, които имат само едно общо нещо:идват от формуляри). Това, което искате, е изпълнимо с бази данни, но би било значително по-лесно да се направи без, но тъй като предполагам, че наистина искате да използвате база данни за това, ето какво бих направил:

• Имате document (или въпросник ), който съдържа множество questions . И двете са достатъчно общи и изискват свои собствени таблици, точно както сте правили досега.
• Всеки въпрос има type който определя какъв вид въпрос е (множествен избор, свободна форма, изберете един... ) и, разбира се, въпросът също има options . Така че това са още две маси. Причината тук е, че отделянето им от действителния въпрос позволява съществуването на определено ниво на абстракция и вашите заявки все пак ще бъдат донякъде прости, макар и вероятно многооооооооооого.

И така, всеки документ има 1..n към въпроси, всеки въпрос има 1 тип и 1..n опции. Пропускайки малко, ето за какво си мисля с таблици с връзки и т.н.

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

Този вид дизайн позволява няколко неща:

• Самите въпроси са за многократна употреба, много удобни, ако правите общ „отговорете на тези x произволни въпроси от група от y въпроси ".
• Новите типове могат да се добавят лесно, без да се нарушават съществуващите.
• Винаги можете да навигирате през структурата доста лесно, например „Какво беше името на документа за този единствен отговор на въпрос, който имам? " или "колко души са отговорили неправилно на този въпрос?"
• Тъй като типовете са разделени, можете да създадете (уеб) потребителски интерфейс, който лесно отразява състоянието в базата данни – още по-добре, ако типът се промени, може дори да не се налага да докосвате кода на потребителския си интерфейс изобщо.
• Тъй като всяка възможна опция за въпрос е отделен ред в QuestionOptions таблица, можете да получите действителната стойност много лесно.

Очевидният проблем с това е, че изисква доста стриктно свързване между таблиците за целостта и ще бъде трудно да се стартира правилно при стартиране. Също така от value в QuestionOptions е varchar, трябва да можете да анализирате много неща и дори може да искате да въведете друго поле за съвети за преобразуване.

Надявам се това да ви помогне, въпреки че изобщо не сте съгласни с моето решение.