動的フォームビルダーフォームとデータベース設計 [閉まっている]

ユーザーが独自のWebベースのフォーム（テキストボックス、選択など）を作成し、ユーザーが入力できるようにWebに公開できるとします。

動的なフォームに結び付けるためにデータベースを設計する方法に関するリソースやアドバイスはありますか？

たとえば、フォームごとに子テーブルを作成しますか、または特定のフォームの異なるバージョンを作成しますか？

通常、ユーザー入力に基づいて新しいテーブルを動的に作成することはお勧めできません。フォームの基本構造が変更された場合、動的に作成されたすべてのテーブルを更新して新しい列を含めるか、古い列を削除する必要があります。これにより、メンテナンスの問題が発生する可能性があります。次に、クエリするテーブルを知る問題があります（おそらく、すべての新しい問題を開く動的SQLにつながるでしょう）。そして、おそらくパフォーマンスの問題もありますが、それがどれほど悪いかはわかりません。また、テーブルは通常、同じエンティティの新しいインスタンスごとに同じテーブルのコピーを保持するのではなく、エンティティのタイプ（「Webフォーム」など）を表すために使用されます。

フォーム用に単一のテーブルを提案します。フォームが誰であるかを識別するには、各フォームに識別子が必要です。

フォーム
-----
  id（PK）
  名
  owner_id（users.idへのFK）
  （その他のフィールド）

form_elements
-------------
  id（PK）
  form_id（forms.idへのFK）
  element_type_id（element_types.idへのFK）
  キャプション
  （その他のフィールド）

element_types
-------------
  id（PK）
  名

element_list_values
-------------------
  id（PK）
  element_id（form_elements.idへのFK）
  名
  値
  （他のフィールド??）

Webアプリケーションでは、ユーザーが作成formsしたユーザーへの参照を使用して、テーブルに保存されるフォームを作成できます（ユーザーを適切なエンティティとして追跡していると仮定します）。フォームはテーブルform_elementsを参照するformsように設定されているため、どのフォームに属してelement_typesいるか、どのタイプであるかがわかります。element_typesフォームが持つことができるさまざまな要素の静的な（大部分）リストを格納します。タイプは、「text_field」、「drop_down_list」、「radio_buttons」、「checkbox」です。「drop_down_list」や「radio_buttons」などのタイプの場合、element_list_valuesこれらの要素が通常持っているリストの可能なオプションを保存するために呼び出される追加のテーブルが必要になります。