7

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

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

  1. クライアントがフィールドの数と、それらのフィールドに関連付けられているラベルのみを定義すると仮定します。4つのテーブルを含むソリューションにたどり着くことができます。 FormDefinition、、、、。FormFieldDefinition_ FormInstances_ FormFieldValuesクライアントはとに変更を加えFormDefinition、FormFieldDefinitionWebアプリはその情報を使用してHTML Webフォームをレンダリングします。このフォームで、Webサイト訪問者（エンドユーザー）がフォームを送信します。このフォームで、新しい行FormInstancesが作成され、値がに保存されます。FormFieldValuesテーブル。

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

    残念ながら、の値列はFormFieldValues、クライアントがWebフォームで指定できる最大サイズのchar型でなければならないことを意味します...フォーム定義が変更されると、古いデータの管理が困難になります。ただし、ユーザーエントリはクエリ可能です（別のピボット質問と同様に、フォームIDを指定してユーザーエントリを一覧表示する簡単なクエリを作成しました）。

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

私の本当の質問は、このデータベースモデルは何と呼ばれているのかということです。（だから私はこの問題をグーグルで検索することができます。）しかし、私は答えを決めるでしょう：どちらがより良い実装ですか、それともそこにもっと良い（または同じくらい良い）実装がありますか？

4

4 に答える 4

3

あなたが説明しているものは、多くの場合「Entity-Attribute-Value」と呼ばれ、「データとメタデータの混合」と呼ばれることもあります。つまり、属性 (フィールド) の名前は文字列 (データ) として格納されます。

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

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

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

編集:アプリケーションでEAVの柔軟性が本当に必要な場合は、それで問題ありません。通常、ルールを破ることを正当化する状況があります。必要な余分な作業に注意し、開発スケジュールで計画し、負荷を処理するためにサーバーをスケーリングします。StackOverflowの EAV に関する私の別の回答も参照してください。

于 2008-10-07T18:21:16.917 に答える
2

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

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

UI のアイデアについては、 http: //wufoo.com/やhttp://frevvo.com/などのフォーム ビルダー サイトも参照してください(Web ベースにする場合)。

于 2008-09-25T07:31:42.300 に答える
1

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

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

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

于 2008-09-25T07:45:53.700 に答える
1

おそらくEntity-Relationship Modelが必要です

そのようなモデルからインタラクティブにスキーマを作成するための GUI ツールが実際にあります。

于 2008-11-04T20:58:20.120 に答える