140

EAV/CRデータベース モデルが悪いと言っても過言ではありません。そうは言っても、

質問:実行時に変更できる e コマース製品を記述する属性の「クラス」を処理するには、どのデータベース モデル、手法、またはパターンを使用する必要がありますか?

優れた電子商取引データベースでは、オプションのクラスを保存します (テレビの解像度のように、各テレビの解像度がありますが、次の製品はテレビではなく、「テレビの解像度」がない場合があります)。それらをどのように保存し、効率的に検索し、ユーザーが製品を説明する可変フィールドで製品タイプを設定できるようにしますか? 顧客が通常、コンソールの深さに基づいてテレビを検索することが検索エンジンによって判明した場合は、フィールドにコンソールの深さを追加し、実行時にテレビ製品タイプごとに 1 つの深さを追加できます。

優れた e コマース アプリには、一連の製品を表示し、「TV 解像度」をヘッダーとして表示できる「ドリルダウン」サイド メニューと、最も一般的なテレビ解像度のトップ 5 を表示する、優れた共通機能があります。見つかったセット。1 つをクリックすると、その解像度のテレビのみが表示され、サイド メニューで他のカテゴリを選択してさらにドリルダウンできます。これらのオプションは、実行時に追加される動的な製品属性になります。

さらなる議論：

簡単に言えば、次のセットアップを「学術的に」修正できるインターネットまたはモデルの説明にリンクはありますか? カテゴリ テーブルを提案してくれた Noel Kennedy に感謝しますが、それ以上の必要性があるかもしれません。以下では、重要性を強調するために別の方法で説明します。問題を解決するために視点の修正が必要な場合や、EAV/CR をさらに深く掘り下げる必要がある場合があります。

EAV/CR モデルに対する肯定的な反応が気に入っています。私の仲間の開発者は皆、Jeffrey Kemp が以下で触れたことを言っています。問題は：

  • エンティティは毎週属性を追加および削除します
    (検索キーワードは将来の属性を決定します)
  • 新しいエンティティが毎週到着し
    ます (製品は部品から組み立てられます)
  • 古いエンティティは毎週消えます
    (アーカイブ済み、あまり人気がなく、季節限定)

顧客は、次の 2 つの理由で製品に属性を追加したいと考えています。

  • 部門・キーワード検索・類似商品比較表
  • チェックアウト前のコンシューマ製品構成

属性には、単なるキーワード検索ではなく、意味がなければなりません。「ホイップ クリームのフロスティング」があるすべてのケーキを比較したい場合は、ケーキをクリックし、誕生日のテーマをクリックし、ホイップ クリームのフロスティングをクリックしてから、ホイップ クリームのフロスティングがあることを知っている興味深いすべてのケーキをチェックします。これはケーキに固有のものではなく、単なる例です。

4

10 に答える 10

75

私が考えることができるいくつかの一般的な長所と短所があります。一方が他方より優れている状況があります。

オプション 1、EAV モデル:

  • 長所: シンプルなアプリケーションの設計と開発にかかる時間が短縮されます
  • 長所: 新しいエンティティを簡単に追加できます (ユーザーによって追加される可能性もありますか?)
  • 長所: 「一般的な」インターフェイス コンポーネント
  • 短所: 単純なデータ型を検証するには複雑なコードが必要
  • 短所: 単純なレポートの SQL がはるかに複雑になる
  • 短所: 複雑なレポートはほとんど不可能になる可能性があります
  • 短所: 大規模なデータセットのパフォーマンスが低い

オプション 2、各エンティティを個別にモデリング:

  • 短所: 要件の収集と設計に時間がかかる
  • 短所: 新しいエンティティは、専門家によってモデル化および設計する必要があります
  • 短所: 各エンティティのカスタム インターフェース コンポーネント
  • 長所: 実装が簡単なデータ型の制約と検証
  • 長所: SQL は書きやすく、理解しやすく、デバッグしやすい
  • 長所: 最も複雑なレポートでも比較的シンプルです
  • 利点: 大規模なデータ セットで最高のパフォーマンスを発揮

オプション 3、組み合わせ (エンティティを「適切に」モデル化しますが、一部またはすべてのエンティティのカスタム属性に「拡張」を追加します)

  • 賛否両論: 要件の収集と設計に、オプション 1 よりも多くの時間が必要ですが、おそらくオプション 2 ほどではありません *
  • 短所: 新しいエンティティは、専門家によってモデル化および設計する必要があります
  • 長所: 新しい属性は後で簡単に追加できます
  • 短所: 単純なデータ型を検証するために必要な複雑なコード (カスタム属性の場合)
  • 短所: カスタム インターフェース コンポーネントは引き続き必要ですが、カスタム属性には汎用インターフェース コンポーネントを使用できる場合があります。
  • 短所: カスタム属性がレポートに含まれるとすぐに、SQL が複雑になります。
  • 短所：カスタム属性で検索またはレポートする必要がない限り、一般的に良好なパフォーマンス

*オプション 3 が設計段階で必ずしも時間を節約できるかどうかはわかりません。

個人的には、オプション 2 に傾倒し、可能な限り EAV を回避します。ただし、一部のシナリオでは、ユーザーは EAV に伴う柔軟性を必要とします。しかし、これには大きな代償が伴います。

于 2009-05-18T06:29:11.650 に答える
64

EAV/CR データベース モデルが悪いと言っても過言ではありません。

いいえ、ちがいます。リレーショナル データベースを非効率的に使用しているだけです。純粋なキー/値ストアは、このモデルでうまく機能します。

さて、あなたの本当の質問: さまざまな属性を保存して検索可能にする方法は?

EAVを使用するだけです。あなたの場合、それは単一の余分なテーブルになります。属性名と値の両方でインデックスを作成すると、ほとんどの RDBM は属性名の繰り返しに対してプレフィックス圧縮を使用し、非常に高速でコンパクトになります。

EAV/CR を使用して「実際の」フィールドを置き換えると、見苦しくなります。どのツールもそうですが、使いすぎは「悪い」ものであり、悪いイメージを与えます。

于 2009-05-15T21:44:54.417 に答える
16 
// この時点で、Magento/ Adobe PSD 形式についてお話ししたいと思います。
// Magento/ PSDは適切な e コマース プラットフォーム/フォーマットではありません。Magento/ PSDは、悪い e コマース プラットフォーム/フォーマットでさえありません。それをそのように呼ぶことは// Zencart や OsCommerce など、
他の悪い e コマース プラットフォーム/フォーマットへの侮辱。いいえ、Magento/ PSDはひどい e コマース プラットフォーム/フォーマットです。持つ
// このコードに数週間取り組んでいますが、Magento/ PSDに対する私の憎しみは猛烈な火にまで成長しました
// それは百万の太陽の激しい情熱で燃えています.

http://code.google.com/p/xee/source/browse/trunk/XeePhotoshopLoader.m?spec=svn28&r=11#107

内部モデルはせいぜい奇抜です。誰かがスキーマをボーグル ゲームに入れ、それを封印し、ペイント シェーカーに入れているようなものです...

実世界: 私はミドルウェア フルフィルメント アプリに取り組んでおり、住所情報を取得するためのクエリの 1 つを次に示します。

CREATE OR REPLACE VIEW sales_flat_addresses AS
SELECT sales_order_entity.parent_id AS order_id, 
       sales_order_entity.entity_id, 
       CONCAT(CONCAT(UCASE(MID(sales_order_entity_varchar.value,1,1)),MID(sales_order_entity_varchar.value,2)), "Address") as type, 
       GROUP_CONCAT( 
         CONCAT( eav_attribute.attribute_code," ::::: ", sales_order_entity_varchar.value )
         ORDER BY sales_order_entity_varchar.value DESC
         SEPARATOR '!!!!!' 
       ) as data
  FROM sales_order_entity
       INNER JOIN sales_order_entity_varchar ON sales_order_entity_varchar.entity_id = sales_order_entity.entity_id
       INNER JOIN eav_attribute ON eav_attribute.attribute_id = sales_order_entity_varchar.attribute_id
   AND sales_order_entity.entity_type_id =12
 GROUP BY sales_order_entity.entity_id
 ORDER BY eav_attribute.attribute_code = 'address_type'

注文の住所情報を遅延して正確に処理します

--

概要: 次の場合にのみ Magento を使用します。

  1. あなたは大金の袋を与えられています
  2. 絶対です
  3. 痛みを楽しむ
于 2010-09-27T21:15:01.263 に答える
15

NoSQL データベースについて誰も言及していないことに驚いています。

私は本番環境で NoSQL を実践したことはありませんが (MongoDB をテストして感銘を受けました)、NoSQL の要点は、さまざまな属性を持つアイテムを同じ「ドキュメント」に保存できることです。

于 2011-04-05T23:10:29.747 に答える
12

ETL タイプのアプリケーションのように、パフォーマンスが主要な要件ではない場合、EAV には別の明確な利点があります。それは、差分保存です。

私は、最初の「バージョン」から現在の状態までのドメイン オブジェクトの履歴を表示する機能が包括的な要件であるアプリケーションを数多く実装してきました。そのドメイン オブジェクトに多数の属性がある場合、それは、変更ごとに対応するテーブルに新しい行を挿入する必要があることを意味します (履歴が失われるため更新ではなく、挿入)。このドメイン オブジェクトが Person であるとしましょう。50 万人の Person を追跡し、Person のライフサイクル全体で平均 100 以上のさまざまな属性への変更を行っているとします。これを、主要なドメイン オブジェクトが 1 つしかないアプリケーションはまれであるという事実と組み合わせると、データベースのサイズがすぐに制御不能になることがすぐに推測できます。

簡単な解決策は、冗長な情報を繰り返し保存するのではなく、主要なドメイン オブジェクトへの差分変更のみを保存することです。

すべてのモデルは、新しいビジネス ニーズを反映するために時間の経過とともに変化します。限目。EAV の使用は、私たちが使用するツールの 1 つにすぎません。しかし、自動的に「悪い」と分類されるべきではありません。

于 2011-07-20T13:04:54.893 に答える
3

私は同じ問題に苦しんでいます。Magento (EAV) と Joomla (通常のリレーショナル構造) の 2 つの既存の e コマース ソリューションに関する次のディスカッションをチェックすることは興味深いかもしれません: https://forum.virtuemart.net/index.php?topic=58686.0

どうやら、Magento の EAV パフォーマンスは本当に目を見張るものがあるようです。

そのため、私は正規化された構造に傾いています。柔軟性の欠如を克服するために、将来、編集可能な別のデータ ディクショナリ (XML または別の DB テーブル) を追加することを考えています。それに基づいて、製品カテゴリを表示し、新しい属性セットと比較するためのアプリケーション コードは次のようになります。 SQL スクリプトと一緒に生成されます。

このようなアーキテクチャは、この場合のスイートスポットのようです。柔軟性とパフォーマンスを同時に実現します。

問題は、ライブ環境で ALTER TABLE を頻繁に使用することです。私は Postgres を使用しているので、その MVCC とトランザクション DDL によって問題が軽減されることを願っています。

于 2009-12-28T10:04:45.803 に答える
2

私は今でも、EAV の最も意味のない原子レベルでのモデリングに投票しています。特定のユーザー コミュニティ向けの標準、テクノロジ、およびアプリケーションによって、コンテンツ モデル、属性の繰り返しの必要性、グレインなどを決定します。

于 2010-05-07T16:58:43.287 に答える
1

少し異なる問題があります。スパース値を持つ多くの属性 (これはおそらく EAV を使用する正当な理由です) の代わりに、スプレッドシートのようなものを保存したいと考えています。シート内の列は変更できますが、シート内ではすべてのセルにデータが含まれます (スパースではありません)。

2 つの設計をベンチマークするための小さなテスト セットを作成しました。1 つは EAV を使用し、もう 1 つは Postgres ARRAY を使用してセル データを保存します。

EAV ここに画像の説明を入力

配列 ここに画像の説明を入力

どちらのスキーマにも適切な列にインデックスがあり、そのインデックスはプランナーによって使用されます。

配列ベースのスキーマは、挿入とクエリの両方で桁違いに高速であることが判明しました。簡単なテストから、どちらも直線的にスケーリングするように見えました。ただし、テストはあまり徹底していません。提案とフォークを歓迎します - それらは MIT ライセンスの下にあります。

于 2016-03-07T05:12:58.260 に答える