動的フォームデータをDBMSに保存し、最適なアプローチを探します

よくある問題に直面しました。静的なもの（事前定義された構造を持つデータベース）を動的なもの（共通点が1つしかない個々のデータセットの束：フォームからのもの）に使用しようとしています。あなたが望むのは実行可能ですデータベースを使用しますが、使用しない方がはるかに簡単です。ただし、これにはデータベースを本当に使用したいと思うので、次のようにします。

documentがあります（またはアンケート ）複数のquestionsが含まれています。これらは両方とも十分に一般的であり、これまでと同じように独自のテーブルが必要です。
各質問にはtypeがありますこれは、それがどのような質問であるかを定義します（複数選択、自由形式、1つ選択... ）そしてもちろん、質問にはoptionsもあります。つまり、さらに2つのテーブルです。ここでの理由は、これらを実際の質問から切り離すことで、ある程度の抽象化が存在し、クエリは多少単純になりますが、おそらく非常に単純であるということです。

したがって、各ドキュメントには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

この種の設計では、いくつかのことが可能です。

質問自体は再利用可能であり、一般的な「y個の質問のプールからこれらのx個のランダムな質問に答える」を作成する場合に非常に便利です。 "。
既存のタイプを壊すことなく、新しいタイプを簡単に追加できます。
構造内をいつでも簡単にナビゲートできます。たとえば、「私が持っているこの1つの質問の回答のドキュメントの名前は何でしたか？ 「または「この1つの質問に間違って答えた人は何人いますか？」
タイプが分離されているため、データベースの状態を簡単に反映する（Web）UIを作成できます。さらに、タイプが変更された場合でも、UIコードにまったく触れる必要がない場合があります。
質問の可能性のある各オプションは、QuestionOptionsの独自の行であるため表を使用すると、実際の値を非常に簡単に取得できます。

これに関する明らかな問題は、整合性のためにテーブル間の非常に厳密な結合が必要であり、開始時に適切に実行するのが面倒になることです。 value以降も QuestionOptionsではvarcharであるため、多くのものを解析できる必要があり、変換ヒント用に別のフィールドを導入することもできます。

私の解決策にまったく同意しなくても、これがお役に立てば幸いです。