2

NodeID |製品テーブルがあります。親ノード ID | 「ノード」は「製品」または「カテゴリ」のNodeNameです。たとえば、次のように言います。

ノード ID | 親ノード ID | ノード名

0|| ||ルート

1|| 0 || エレクトロニクス

2 || 1 || 携帯電話

3 || 2 || サムスン

4 || 2 || アップル

5 || 2 ||ノキア

6 || 5 || ノキア1100

7 || 5 || ノキア Lumia 800

等々..

ここで、Root > Electronics > Nokia がカテゴリで、Nokia 1100 が製品です。製品ごとに、製品に関連する特定の属性 (仕様) のセットが必要です。私は列を持つテーブルProductAttributesでその関係を維持しています: AttributeId || 属性名 || 値 || 特定のNodeID (Nokia 1100 など) のすべての属性とそれに対応する値を保持する NodeID。

したがって、ユーザーが「Nokia 1100」を投稿すると、UI に値が事前に入力されたすべての属性が表示されます。

ユーザーが投稿しているものがデータベースにない場合を考えてみましょう。彼は「Samsung Focus」を投稿していると言います。このリクエストを投稿する「カテゴリ」、この場合は「モバイル」を選択するオプションが表示されます。

したがって、私が望むのは、モバイルに関連する属性のみ (デフォルト値あり/なし) をユーザーに表示し、ユーザーが該当するものを選択してリクエストを投稿できるようにすることです。

このために、私はいくつかのデフォルトの属性を「カテゴリ」に入れることを考えています。これは、彼がそのカテゴリを選択するたびに利用できるようになります。

しかし、このアプローチと関係のための適切なテーブル構造を思いつくことができません。つまり、1 つのカテゴリに複数の属性が存在し、各属性に複数の値が存在する可能性があります。

私がここでやろうとしていることを描写できることを願っています。

4

1 に答える 1

0

EAV(エンティティ属性値)パターンを探しているようです

http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model

ただし、このアプローチ(アンチパターンと言う人もいます)には落とし穴が散在していることに注意してください。

于 2012-09-24T14:51:02.340 に答える