2012-02-03 8 views
2

管理者がプログラムでフォームを作成し、ユーザーがフォームにデータを入力できるシステムを構築したいと考えています。また、管理者は、選択可能な複数の選択肢の質問であっても、フォームにフィールド名を入力できる必要があります。 私は、生成されたすべてのフォームタイプに対して巨大なテキストブロックを作成し、フォームフィールド、名前、選択肢などを配列やオブジェクトから直列化して格納することしかできません。 私は、ユーザーの回答を別のテキストブロック内の直列化された配列で保持し、それぞれの配列に配列の位置を割り当てます。ダイナミックデータベースフィールドを維持する最も良い方法は?

この問題にはより良いアプローチがありますか?

+0

私はこの愚かな標準Q&Aフォーマットのものに悩まされ始めました。申し訳ありませんが、私はこの情報を少なくともいくつかの経験を持っている人から必要としていました。少しスクロールするだけであれば人々は私を助けました。どちらが良いか、他の人が吸うかについての不必要な議論はありませんでした。また、これは回答者の1人が「データベースでそれをしないでください、もっと良い方法です」と言うかもしれません。それは私にとっても重要です。私はこの閉鎖のようなナチは理由があると思う。落ち始めます。太陽のような偉大なコミュニティを壊さないでください – gkaykck

答えて

4

EAV data modelがあなたの目的に合っているかもしれません。参照整合性の欠如や、データを取得するための長い問合せ(戻す必要のあるすべての属性には別のJOINが必要です)など、いくつかの短所があります。

0

"Fields"のような名前のテーブルをデータベースに作成できますか?各フィールドにはタイプとテキストがあります。またoptionsというテーブルもあります。このテーブルにはオプションのテキストフィールドと、フィールドテーブルを指すfkという異なるテキストフィールドがあります。また、fieldsテーブルにfkを持つフォームテーブルがあります。アプリのコードでは、フィールドを見て、オプションを取得する必要があるかどうかを判断できます。これはリレーショナルデータベースのアプローチです。 Mongoのようなオブジェクトデータベースの中には、これをもっとうまく処理できるものがあります。

表:フォーム カラム:Form_ID PK

表:フィールド カラム:FIELD_ID PK カラム:テキスト カラム: 列を入力しForm_ID(FK)

を要約する

テーブル:オプション カラム:Option_ID カラム:テキスト カラム:Field_ID(FK)

2

これにはさまざまな方法があります。リレーショナルデータベースを扱っているので、1つの選択肢はEntity-Attribute-Value modelです。実際には、このアプローチは、データ構造を事前定義されたスキーマ(列)から行に切り替えます。この柔軟性には多くの欠点があります。多くの場合、この「回転した」データの一部をより伝統的な表の形式で表示するための一連のビューを構築することになります。

一部のリレーショナルデータベースでは、SQLタイプの機能は提供されないため、その解決策を見つけることができます。たとえば、PostgreSQLにはhstoreタイプがあります。これにより、キーと値のペアのセットを単一の値に格納できます。私はあなたの質問にPostgreSQLについて言及していないことを認識していますが、そこに何があるのか​​を知っているだけでなく、9.2用のネイティブなJSONデータ型と関数スイートに取り組んでいます。機能インデックスと組み合わせることで、RedisやMongoDBのようなものがなくても、興味深いリレーショナル/

関連する問題