8

私はしばらくの間、eBay のような分類法と特定の製品カテゴリに依存する属性を使用して、典型的な e コマース サイトをモデル化することについて考えてきました。

最初の試みは、EAV と Table Per Class db 継承モデリングのどちらかを選択することでした。パフォーマンスのために後者を選択しましたが、それが意味することは、個別の列としてモデル化された特定のカテゴリ属性 (テレビの解像度など) を持つ特定の (カテゴリ ツリーの葉) 製品カテゴリごとに専用のテーブルを作成することでした。

既存のカテゴリに属性を追加したり、新しいカテゴリを追加したりする必要がある場合、この設定は効率的ですが、柔軟ではありません。このような変更ごとに、次のものが必要です。

  • テーブルの変更/作成
  • このようなカテゴリを特定の属性でフィルタリングするための新しいフォーム
  • 検索およびフィルタリング用のデータベース クエリを生成するための新しいコード
  • 新しいカテゴリの製品を表示するためのいくつかの新しいビューモデル/DTO およびビュー

その複雑さに対処するには、これらの属性のある種のメタ表現が (アプリケーションの外部であっても) xml または Excel ファイルで必要であると思います。これにより、変更のたびに、言及されたすべてのコードが自動生成されます (sql/orm クエリ、アプリケーションコード、テンプレート)。したがって、開発には役立ちますが、それでもテストと追加の展開が必要です。

その時点で、eBay は実際には検索にリレーショナル データベースを使用しておらず、分類法が非常に柔軟であるため、新しいリーフ カテゴリを非常に迅速に追加できることを知りました。また、それらのカテゴリは、おそらくリレーショナル データベースでモデル化された階層ツリーのカテゴリではなく、単に検索属性 (ファセット) です。

最も有望な専用のファセット検索セットアップ (個別の Solr インスタンス) を簡単に調べた後、分類法の変更に柔軟に対応できるかどうかはわかりません。通常、Solr は何らかの形でリレーショナル DB をミラーリングするだけなので、特定のカテゴリ属性は依然としてDBMS メタデータとして DB でモデル化されます。属性をフィルタリングするための UI フォームを動的に生成することは、次の場合を除いて困難です。

1) EAV ファシオンを使用してデータを RDBMS に保持し、SOLR 検索を使用してパフォーマンスの問題を克服します (ただし、EAV の乱雑さ、データ整合性の強制などの問題はまだあります)

2) RDBMS に属性ディクショナリ (名前と型のみ) だけを保持し、検索機能とは別に非リレーショナル データ ストアのようなものとして使用して、特定の属性値を SOLR に格納します。アプリケーションがsolrと緊密に結合されるため（つまり、製品版の管理者CRUDがSOLRと直接やり取りするため）、このソリューションにも（たとえそれが可能であったとしても）確信が持てません。

あなたの考えは何ですか？このような (パフォーマンスの高い) 分類法では、柔軟なコード生成は避けられないと思いますか? それをどのように処理しますか？コード生成のためだけに、DB で EAV 方式の別のデータ ディクショナリがあるのでしょうか。MongoDB のようなものも使用できると思いますが、UI コードの生成 (実行時かどうかに関係なく) には何らかのメタデータが必要です。

ここには多くの質問がありますが、より大きなクラスの問題を扱うときの一般的な設計アプローチに興味があるため、小さな質問に分割したくありませんでした。

4

2 に答える 2

3

私はこれらすべてに対する決定的な答えを持っているとは主張していません (これはかなりオープンエンドの質問であり、より小さな部分に分割しようとする必要があり、実際の要件によって異なります。実際、私はそれを閉じることに投票したくなります）しかし、私はいくつかのことについてコメントします：

  1. これを RDBMS でモデル化することを忘れてしまいます。ファセット検索は、リレーショナル スキーマでは機能しません。
  2. IMO これはコード生成に適した場所ではありません。データの変更によって変更されないようにコードを設計する必要があります (スキーマの変更について話しているわけではありません)。
  3. メタデータ/属性を Excel スプレッドシートに保存することは、非常に悪い考えのように思えます。これを編集するための UI を構築します。これは、Solr / MongoDB / CouchDB など、これを管理するために選択したものに保存されます。
  4. Solrは「リレーショナル DB をミラーリングするだけ」ではありません。実際、Solr はリレーショナル データベースから完全に独立しています。最も一般的なケースの 1 つは、 RDBMS から Solr へのデータのダンプ (処理中のデータの非正規化) ですが、Solr はリレーショナル データ ソースがなくても機能するほど柔軟です。
  5. Solrの階層ファセットは、まだ研究中の問題です。現在、2 つの別々のアプローチが研究されています ( SOLR-64、SOLR-792 ) 。
于 2010-01-17T16:05:18.750 に答える
0

さまざまな種類の製品にさまざまな種類のカテゴリがあるとしたら?

eBay の例では、本またはテレビ/ディスプレイのいずれかの製品があります。

本にはタイトルと ISBN があり、SF のカテゴリ、エロティックなカテゴリ、ノンフィクションのカテゴリ、自伝的なカテゴリのいずれかになります。または、ノンフィクションの自伝的なエロチックなカテゴリの本を持っているかもしれません。

ディスプレイには画面解像度とワット消費量 (?) があり、フラット スクリーン カテゴリ、CRT カテゴリ、または HD カテゴリに分類される場合があります。

純粋にリレーショナルな観点から、次のようにモデル化できます。

[Product]-(1)------(1)-[  Book  ]-(n)------(m)-[ book_category ]
| id    |              | title  |              |  name         |
| price |              | ISBN   |
| ...   |
| ...   |-(1)---(1)-[   display  ]-(n)------(m)-[ display_category ]
                    | resolution |              |  name            |
                    |   watts    |

モデリングの代わりに、製品のタイプ/クラスに応じattributes dependent on a particular product categoryてさまざまなプロパティとカテゴリがあります。

スーパータイプとサブタイプを見る

于 2012-07-03T20:33:38.170 に答える