1

ユーザーが独自のWebフォームを作成して公開できるようにするwufooのようなオンラインフォームビルダーを構築したいと思います。各提出物は、ユーザーが後で提出物を取得できるデータベースに保存する必要があります。

これらのフォームは動的になるため、つまり。ユーザーはフォームフィールドの量とタイプを完全に制御できます。私はこの情報を格納するための堅固なデータベース設計を考えようとしています。

ユーザーが利用できるすべてのタイプのフィールドを含む1つのテーブルフィールドタイプがあります。textfield、emailfieldなど。

各フォームID、URLなどを保持する1つのベースフォームテーブル。

次に、ベースフォームとフィールドタイプへの参照を含むテーブルフォームフィールドがあります。このテーブルには、各フィールドで実行されるカスタム検証を含めることもできます。

このデザインは基本構造として良いですか？アプリケーションに新しいタイプのフィールドを追加するのは簡単だと思いますが、SQLの専門家から遠く離れているため、潜在的な欠点が何であるかはわかりません。

4

2 に答える 2

1

ユーザー定義データをSQLに保存する

次のようなエンティティ-属性-値データベースモデルを探していると思います。

基本的な考え方は、属性とそれに対応する値を1つのテーブルの行として格納することです。

通常、テーブルには、エンティティ、属性、値の少なくとも3つの列があります。ただし、アプリケーション構成やオプション設定のテーブルなど、関連するエンティティが1つしかない場合は、エンティティ列を除外できます。

開始点としてこのページを参照してください。

質問をタグで再タグ付けしました。このタグでは、ケースに関連する多くのスレッドを参照できます。

于 2012-09-06T12:42:46.313 に答える
0

Mahmoud Gamal が書いているように、あなたが説明するモデルは「エンティティ/属性/値」です。Borys が書いているように、このモデルには多くの既知の問題があります。

別の方法として、リレーショナル モデル内の "ドキュメント" (XML や JSON など) にフォーム エントリを格納することを検討することもできます。

たとえば、次の行に沿ったテーブルがあるとします。

FORM_SUBMISSION
--------------------
Submission_ID (pk)
Client_ID (fk to clients table)
Submission_date
SubmissionDocument

フォームを作成するユーザーを表すために「クライアント」を使用しています。特定のクライアントのすべての送信を取得するには、client_id で where 句を使用します。

このモデルでは、フォームの送信に対して SQL クエリを実行するのが難しくなります (非常に単純なクエリを超えると、EAV でも難しくなります) が、永続化ソリューションは劇的に簡素化されます。

于 2013-08-10T10:33:37.563 に答える