製品属性のデータベーススキーマ

Question

カテゴリでフィルタリングする製品を実装したいのですが、正しいDBスキーマについて質問があります。 今の私は、次の表があります。

カテゴリー：

1. id 
2. category 
3. description 

製品：

1. id 
2. category_id 
3. product 
4. image 
5. price 

属性：

1. id 
2. attribute 

Category_Attributes：

1. category_id 
2. attribute_id 

そして、私が持っている問題は、彼らが値の種類を格納する必要が叫ぶ何の表Iは、作成する必要があり、何列である属性値を、製品には、属性値など

う

値：

つの以上のテーブルを作成するために正常です10

Attributes_Values：

1. attribute_id 
2. value_id 

Products_Attributes_Values：

1. product_id 
2. attribute_id 
3. value_id 

私は最後のテーブルにめちゃくちゃました。保存してフィルタリングする方が良いでしょうか？あなたが達成しようとしている何

Answer 1

はエンティティ - 属性値（EAV）または可能性行モデリングソリューションです。このタイプの構造は、多種多様な理由のために大いに眉をひそめていることに注意してください。

しかし、私はEAVはそれがない場合を除き、悪であること（例えばhere、here、here、およびhere）主張してきました。それらのまれな例外の1つは、製品の特性を追跡する製品カタログの場合で、これらの特性が興味深いものではない場合（システムへ！）、これらを取得して印刷する必要がある場合を除きべき

は、あなたが特定のカテゴリの製品をどの属性を記述している。このようなモデルでやっている：商品等のWebページや比較グリッド、上

は、このようなデザインを考えてみましょうそれらの属性が持つ可能性のある値、各特定の製品が持つ価値ch属性。

このデザインには、EAVが課す通常の制限がすべてあります。しかし、「どのビーズの直径が8mmですか？」などの質問をする場合は、それはかなり簡単です。