初めての E コマース データベースを設計しようとしています。
私がほとんどの E コマース Web サイトで見つけたのは、これらのサイトにはカテゴリ、サブカテゴリ、サブカテゴリなどがあるということです。SubCategory の深さは固定されていません。つまり、1 つのカテゴリには 6 つのネストされたサブカテゴリがあり、他のカテゴリには異なるサブカテゴリがあります。
これで、すべての製品に属性が関連付けられました。
私の質問は、これらの Web サイトがネストされたサブカテゴリのテーブルを追加し続け、データベースに属性の列を追加し続けていることです。
また
彼らは「EAV」モデルと呼ばれるものを適用してこの問題を解決するか、列やテーブルを追加し続け、多くのサイトで新しいカテゴリがあることを発見したため、Webページを更新し続けます.
(EAV モデルを使用すると、Web サイトのパフォーマンスが影響を受けますね..)
これは私の最初の E コマース プロジェクトであるため、貴重な提案をいくつか提供してください。
ありがとう、
どんな助けでも大歓迎です。
必要なのは、製品機能のEAVと製品カテゴリのネストされたセットの組み合わせです。
EAVはほとんどの場合悪い選択であることに私は確かに同意しますが、EAVが最適な選択である1つのアプリケーションは、オンラインカタログの製品属性を処理するためのものです。
Webサイトが製品属性をどのように表示するかを考えてください...製品の属性は、常に2つの列を持つ垂直リストとして表示されます。"価値"。これらのリストには、複数の製品を並べて比較している場合があります。EAVは、この種のことを行うのに最適です。EAVをほとんどのアプリケーションにとって無意味で非効率的なものにしているのは、まさにオンラインカタログの製品属性にとってEAVを意味のある効率的なものにしている理由です。
誰もがいつも「EAVは悪だ！」と言う理由のひとつ。つまり、EAVの属性は、列名（つまり、属性の意味）がテーブル駆動型であり、したがってスキーマによって定義されていない限り、「無意味」です。スキーマの要点は、モデルに意味を与えることであるため、この点はよく理解されています。 ただし、オンライン製品カタログの場合、製品属性の意味はシステム自体にとって実際には重要ではありません。カタログシステムが製品属性を気にする唯一の理由は、それらをリストまたは場合によっては製品比較マトリックスにダンプすることです。したがって、この特定のケースでは、EAVが悪になることはありません。
製品カテゴリの場合、この質問への回答で説明したように、入れ子集合モデルが必要です。入れ子集合は、編集時に事前計算の労力を犠牲にして、不均衡な階層の複数のレベルをトラバースする機能とともに、非常に迅速な検索を提供します。