クライアントが作成および変更可能な Web フォームをリレーショナル データベースに実装するのに最適なものは何ですか?

Question

私が参加したいくつかの Web アプリケーション プロジェクトでは、クライアントが独自のフォームを作成できるようにすることを求めています。フォーム定義を保存する方法と、ユーザーが入力した値をカスタム フォームに保存する方法について疑問が生じます。

私はこれが 2 つの方法で行われるのを見てきました。

1. クライアントはフィールドの数と、それらのフィールドにどのラベルが関連付けられるかを定義するだけであると仮定します。4 つのテーブルを含む解決策に到達できます。 FormDefinition, FormFieldDefinition, FormInstances, FormFieldValues. 。クライアントが変更を加える FormDefinition そして FormFieldDefinition, 、Web アプリはその情報を使用して HTML Web フォームをレンダリングします。Web サイト訪問者 (エンド ユーザー) はこのフォームにフォームを送信します。 FormInstances が作成され、値が FormFieldValues テーブル。

   行数 FormDefinition フォームを定義します。つまり、 form definition ID = 2, form title = 'Car Registration Form'. 。行数 FormFieldDefinition フォームのフィールドを定義します FormDefinition, 、つまり field definition ID = 7, field label = 'Car Model', field type = 'varchar(50)'. 。行数 FormInstance ユーザーが記入した各フォームのインスタンスです。つまり、 definition id = 2, date_entered = '2008-09-24'. 。そして列に並ぶ FormFieldValues ユーザーによるエントリです。つまり、 field definition = 7, value = 'Tiburon'.

   残念ながら、それは次の値列を意味します。 FormFieldValues クライアントが Web フォームで指定できる最大サイズの char 型である必要があります...また、フォーム定義が変更されると、古いデータの管理が曖昧になります。ただし、ユーザーエントリはクエリ可能です（私は クイッククエリ これは、フォーム ID を指定してユーザー エントリをリストします。これは次のようになります。 別の重要な質問).

2. 4 つのテーブルを使用する代わりに、フォーム定義とユーザーのフォーム エントリを XML (または YAML など) にシリアル化し、それをテキストとして保存することもできます。利点は、フォームがデータベース内で人間が判読できることです。欠点は、XML の解析に伴うアプリケーションのオーバーヘッドが増加し、SQL の観点からデータベースのクエリが大幅に困難になることです。

私の本当の質問は、このデータベース モデルは何と呼ばれるのかということです。(したがって、この問題をグーグルで検索できます。) しかし、私なら次のような答えに落ち着きます。どちらの実装がより優れていますか、それともより優れた (または同等の) 実装は存在しますか?

Answer 1

あなたが説明していることは、しばしば「エンティティアトリブの価値」と呼ばれ、時には「データとメタデータの混合」と呼ばれます。つまり、属性の名前（フィールド）は文字列（データ）として保存されます。

これは、各フォーム インスタンスに同じフィールド セットが含まれていることを確認することや、必須フィールドが入力されていることを確認すること (従来のテーブルの NOT NULL に相当) など、一連の複雑な問題を引き起こします。

リレーショナル データベースでこれを行う最善の方法について質問されました。リレーショナル データベースでは、メタデータにはメタデータを使用する必要があります。この場合、フォームごとに新しいテーブルを作成し、フォームフィールドに列を使用することを意味します。したがって、フォーム定義は単なるテーブルのメタデータであり、1 つのフォーム インスタンスはそのテーブル内の 1 行になります。複数の値の回答を含むフォームをサポートしている場合 (例:チェックボックス)、依存テーブルも必要です。

これは高価であるか、拡張するのが難しいように思えるかもしれません。おそらく本当でしょう。したがって、リレーショナル データベースはこの仕事には最適なツールではない可能性があります。XML または YAML の可能性について言及しました。基本的には、アドホックに定義できるある種の構造化されたファイル形式です。収集された各フォームを検証できるように、クライアントのフォームごとに DTD を定義する必要があります。

編集： アプリケーションで EAV の柔軟性が本当に必要な場合は問題ありません。通常、ルールを破ることが正当化される状況があります。追加の作業が必要になることに注意して、開発スケジュールや負荷を処理するためにサーバーを拡張する際に、その作業を計画してください。別のものも参照してください EAVについての私の答え スタックオーバーフローで。

Answer 2

このデータベース モデルは何と呼ばれますか?

実際に何と呼ぶべきかはわかりませんが、アンケートを動的に生成するときに使用されるプロセスと同じです。調査アプリケーションを生成するためのソースを探すと、同じ一般的なデータベース スキーマと同様の方法が見つかります。

次のようなフォームビルダーサイトも調べてください。 http://wufoo.com/ または http://frevvo.com/ UI のアイデア (Web ベースにしている場合)。

Answer 3

3 番目のオプションでは、テーブルを作成し、必要に応じて列を追加します。作成されるフォームの数によって異なりますが、データベースは多くのテーブルを簡単に処理できます。したがって、ユーザーがフォーム「Car Registration Form」を追加したい場合は、テーブル「CarRegistrationForm」を追加します。フォームに必要なフィールドごとに、日付、整数、テキストなどの基本的な型の中から選択できるようにすることができます。また、テキストを選択する場合は、選択リストから最大長を入力する必要があります。これにより、フィールドが varchar であるべきか clob であるべきかの情報が得られます。

これは SQL Server で機能し、列を簡単に追加および削除できます。DB2 の場合、ドロップ列が実装されていないため、問題が発生する可能性があります。mysqlについてはよくわかりません。

フォームとそのフィールドを 2 つの別々のテーブルに登録する必要があります。

Answer 4

あなたはおそらく欲しいでしょう エンティティ関係モデル

実際、そのようなモデルから対話的にスキーマを作成する GUI ツールがあります。