27

現在、e コマース プラットフォームの製品セクションのデータベース構造を設計しています。無数の異なる属性を持つ無数の異なる種類の製品を販売できるように設計する必要があります。

たとえば、ラップトップの属性は、RAM、画面サイズ、重量などです。書籍の属性は、著者、ISBN、出版社などです。

EAV構造が最適と思われます。

  • 商品を選択してください
  • 製品は属性セットに属します
  • 属性セットには属性 x および y が含まれます
    • 属性 x はデータ型 datetime です (値は attribute_values_datetime に格納されます)
    • 属性 y はデータ型 int (attribute_values_int に格納される値) です。
  • 各属性定義は型を示します (つまり、x には列型 -> 日付型があります)

上記を仮定すると、選択を attribute_values_datetime テーブルに結合して、結果セットを取得せずに適切なデータを取得し、テーブルがわかっているので 2 番目のクエリを作成できますか? このタイプのクエリを作成すると、パフォーマンスに大きな影響がありますか、それとも以下の方が適していますか (機能は劣りますが)

  • 商品を選択してください
  • 製品は属性セットに属します
  • 属性セットには属性 x および y が含まれます
    • 属性 x はデータ型 datetime ですが、attribute_values に TEXT として格納されます
    • 属性 y はデータ型 int ですが、attribute_values に TEXT として格納されます
4

3 に答える 3

34

この質問に対するほとんどのコメントに対して、私は反対の意見を述べます。SO やDBA.SEなどで何度も徹底的に説明されているすべての理由から、EAV は悪ですが、EAV の問題点のほとんどがほとんど無関係であり、(いくつか) EAV の利点は非常に密接です。そのアプリケーションは、オンラインの製品カタログです。

EAV の主な問題は、データベースが本当に得意とすることを実行できないことです。これは、さまざまなエンティティに関する情報のさまざまな属性に、適切なコンテキストをスキーマに配置することによって提供するのに役立ちます。スキーマを使用すると、データへのアクセス、解釈、および整合性の強化に関して、非常に多くの利点がもたらされます。

製品カタログに関する事実は、製品の属性がカタログ システム自体とはほとんど無関係であるということです。製品カタログ システムは、製品属性を使用して (多くても) 3 つのことを行います。

  1. {attribute name}: {attribute value} の形式で製品属性をエンド ユーザーにリスト表示します。

  2. 異なる製品の属性が互いに並んでいる比較グリッドに、複数の製品の属性を表示します (通常、製品は列であり、属性は通常行です)。

  3. 特定の属性/値の組み合わせに基づいて、何か (価格設定など) のルールを駆動します。

システムが (システムにとって) 意味的に無関係な情報を逆流させるだけである場合、この情報のスキーマは基本的に役に立ちません。実際、オンライン製品カタログではスキーマが邪魔になります。特に、カタログにさまざまな種類の製品が含まれている場合は、常にスキーマに戻って、新しい製品カテゴリまたは属性タイプを許可するためにスキーマをいじる必要があるためです。 .

その使用方法のために、製品カタログの属性値のデータ型でさえ、必ずしも (非常に) 重要ではありません。属性によっては、「数値でなければならない」や「このリスト {...} から取得する必要がある」などの制約を課したい場合があります。それは、属性の一貫性がカタログにとってどれほど重要であるか、および実装をどれだけ精巧にしたいかによって異なります。いくつかのオンライン小売業者の製品カタログを見ると、ほとんどの小売業者は一貫性のためにシンプルさを犠牲にする準備ができていると言えます.

はい、そうでない場合を除いて、EAVは悪です。

于 2012-08-15T15:13:03.197 に答える
2

はい、通常、EAV モデルのクエリを組み立てるには大きなペナルティがあります。データの自己整合性をチェックすると、パフォーマンスが大幅に低下します。これは、DBMS がそれを行うことができないためです。何か問題が発生した場合、DBMS では通知できません。

コメントでOdedが推奨するように、よりオーソドックスなデータベース設計により、DBMS はデータベース内のデータがより一貫性を保てるようにします。通常の (非 EAV) 設計を使用することを強くお勧めします。

于 2012-08-12T05:00:13.460 に答える
2

これがコメントなのか回答なのかわかりません。それにもかかわらず、ここに行きます。

何を構築しているのか正確にはわかりません。しかし、Magento EAV データベース構造を調べましたか? はい、遅くなる可能性があり、クエリが巨大になる可能性がありますが、私たちにとってプラスはマイナスよりも大きい. 一方、magento はクエリを処理します。

現在、オンライン ストア (中規模から大規模のストア) を Magento に移行中ですが、今のところ、EAV アプローチに非常に満足しています。

于 2012-08-02T14:23:09.783 に答える