エンティティ-属性-値テーブルの設計
私は現在、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として格納されます
私はこの質問に対するほとんどのコメントに反対の意見を述べるつもりです。 EAVはEVILここで何度も徹底的に説明されている理由のすべてのためにSOおよびDBA.SEおよび他の場所で、1つの本当に一般的なアプリケーションがありますEAVで間違っていることのほとんどはほとんど無関係であり、EAVの（いくつかの）利点は非常に密接な関係があります。そのアプリケーションはオンライン製品カタログです。
EAVの主な問題は、データベースが実際に得意なことを実行できないことです。これは、さまざまなエンティティに関する情報のさまざまな属性に、それらをschemaに配置することで、適切なコンテキストを与えるのに役立ちます。 =。スキーマを持つことは、データへのアクセス、解釈、および整合性の実施に関して多くの利点をもたらします。
製品カタログに関する事実は、製品の属性はほとんど完全に無関係であるということですカタログシステムに対してそれ自体。製品カタログシステムは、（多くても）製品属性で3つのことを行います。
{属性名}：{属性値}の形式でエンドユーザーにリストの製品属性を表示します。
異なる製品の属性が互いに並んでいる比較グリッドに複数の製品の属性を表示します（製品は通常列、属性は通常行）
特定の属性/値の組み合わせに基づいて、何か（価格設定など）のルールを推進します。
システムが（システムに）意味的に無関係な情報を逆流させるだけの場合、この情報のスキーマは基本的に役に立ちません。実際、オンライン製品カタログのスキーマ邪魔になる特にカタログにさまざまな種類の製品が含まれている場合は、スキーマに戻ってそれをいじくり回す必要があるためです。新しい製品カテゴリまたは属性タイプの場合。
使用方法が原因で、製品カタログの属性値のデータ型でさえ、必ずしも（非常に）重要であるとは限りません。一部の属性では、「数値である必要があります」や「このリストから取得する必要があります{...}」などの制約を課すことができます。これは、カタログにとって属性の一貫性がどれほど重要であるか、および実装をどの程度複雑にするかによって異なります。いくつかのオンライン小売業者の製品カタログを見ると、ほとんどの場合、単純さと一貫性をトレードオフする準備ができていると思います。
はい、そうでない場合を除いて、EAVは悪です。
これがコメントなのか答えなのかわかりません。それにもかかわらず、ここに行きます。
何を作っているのか正確にはわかりません。しかし、 Magento EAVデータベース構造 を調べましたか？はい、それは遅くなる可能性があり、クエリは巨大になる可能性がありますが、私たちにとってプラスはマイナス以上です。一方、magentoがクエリを処理します。
私たちはオンラインストア（中規模から大規模のストア）をMagentoを使用するように移行している最中であり、今のところEAVアプローチに非常に満足しています。
はい、通常、EAVモデルのクエリを組み立てるには大きなペナルティがあります。データの自己整合性をチェックすることには、DBMSがそれを行うことができないため、より大きなパフォーマンスのペナルティがあります。何か問題が発生した場合、DBMSはそれを通知できません。
コメントの Oded で推奨されているように、よりオーソドックスなデータベース設計により、DBMSはデータベース内のデータの一貫性をより確実にします。通常の（EAV以外の）設計の使用を強くお勧めします。