4

新しいアプリケーションを開始しましたが、現在2つのパスを調べていますが、どちらが続行するのが良いかわかりません。
私はeコマースサイトのようなものを構築しています。カテゴリとサブカテゴリがあります。問題は、サイト
にはさまざまな種類の製品があり、それぞれが異なるプロパティを持っていることです。また、サイトはこれらの製品プロパティでフィルタリングできる必要があります。
これは私の最初のデータベース設計です：

Products{ProductId, Name, ProductCategoryId}
ProductCategories{ProductCategoryId, Name, ParentId}
CategoryProperties{CategoryPropertyId, ProductCategoryId, Name}
ProductPropertyValues{ProductId, CategoryPropertyId, Value}

分析の結果、このデザインは実際にはEAVモデルであることがわかり、通常、このデザインは推奨されないことがわかりました。
すべてに動的SQLクエリが必要なようです。

それは一つの方法であり、私は今それを見ています。

私が見る別の方法は、おそらくLOT WORK WAYという名前ですが、それが良ければそこに行きたいと思います。テーブルを作るには

Product{ProductId, CategoryId, Name, ManufacturerId}

データベースでテーブル継承を作成するということは、次のようなテーブルを作成することを意味します。

Cpus{ProductId ....}
HardDisks{ProductId ....}
MotherBoards{ProductId ....}
erc. for each product (1 to 1 relation).

これは非常に大規模なデータベースと非常に大規模なアプリケーションドメインになることを理解していますが、EAV設計のオプションよりも優れており、簡単で、パフォーマンスも優れています。

4

3 に答える 3

5

EAV is rarely a win. In your case I can see the appeal of EAV given that different categories will have different attributes and this will be hard to manage otherwise. However, suppose someone wants to search for "all hard drives with more than 3 platters, using a SATA interface, spinning at 10k rpm?" Your query in EAV will be painful. If you ever want to support a query like that, EAV is out.

There are other approaches however. You could consider an XML field with extended data or, if you are on PostgreSQL 9.2, a JSON field (XML is easier to search though). This would give you a significantly larger range of possible searches without the headaches of EAV. The tradeoff would be that schema enforcement would be harder.

于 2013-03-07T15:38:43.410 に答える
4

この質問は、この問題をより詳細に議論しているようです。

そこで説明されているパフォーマンス、拡張性、複雑さの他に、次の点も考慮に入れます。

  • SQL ServerなどのSQLデータベースには、全文検索機能があります。したがって、製品を説明する単一のフィールドがある場合、全文検索はそれを索引付けし、高度なセマンティック検索を提供できるようになります

  • 現在大流行しているno-sqlシステムを見てください。スケーラビリティはそれらで非常に優れているはずであり、それらはあなたが持っているような非構造化データのサポートを提供します。HadoopとCasandraは良い出発点です。

于 2013-03-06T15:05:34.290 に答える