1

私の Web アプリケーションのユーザーが製品の独自の属性を定義し、それらの製品のデータを入力できるようにしたいと考えています。この技法が と呼ばれていることがわかりましたn(th) normal form。

以下は、私が現在導入を検討している DB 構造であり、整合性とスケーラビリティ (および考えられるその他の要素) に関して、長所と短所がどうなるか疑問に思っていました。

元の図

編集 （申し訳ありませんが、これは私が意味するものです）

新しい図

私は過去 15 分間これを見つめていましたが、(赤い矢印の場所) が重複を誘発するため、整合性チェックが必要になることがわかっています。しかし、私がやりたいことを他にどのように行うことができるのか理解できません。

製品の数は 10 を超えません。変数の数は 200 を超えません (製品ごとに最大 20)。製品インスタンスの数は 100,000 を超えないため、の最大サイズはpVariable_data200 万を超えません

4

2 に答える 2

2

このモデルはデータベースの中のデータベースと呼ばれていて、良くありません。場合によっては、最初にそれが本当に必要かどうか、データベースが実際にジョブに適したデータベースであるかどうかを確認することが不可能な場合もあります。

PostgreSQLでは、この種の問題に対する標準化されたソリューションであるhttp://www.postgresql.org/docs/8.4/static/hstore.htmlを使用できます。

于 2012-06-30T12:36:35.060 に答える
0

pVariable がより pVariable 型であると仮定して、product_fk への参照をドロップします。これは、Product レコードごとにそのテーブルに新しいエントリが必要であることを意味します。たぶん、次のようなことを試してください：

Product(id, active, allow_new)

pVariable_type(id, name) 

pVariable_data(id, product_fk, pvariable_fk, non_typed_value, bool, int, etc)

non_typed_value をテキスト値として使用し、(ストリームを保持していない限り) 型指定された値と一緒にそのフィールドにレコードを書き込みます。これは、レコードの値を 2 回保持することを意味します (そして、更新などの手間がかかります) が、レポート (値を表示するだけでよいもの) とともに、クエリが容易になります。

注: すべての製品に共通するものを取り出して、製品テーブルに入れることも考えられます。たとえば、ほとんどの場合、すべての製品に名前、希望価格などがあります。

于 2012-06-30T12:40:19.317 に答える