11

短い質問:複数のカテゴリの下に表示される製品カテゴリはどのように管理する必要がありますか? そうするのは悪い習慣ですか？

背景情報: 次 のようなカテゴリの製品データベースがあります。

Products

  -Arts and Crafts Supplies
    -Glue
    -Paper Clips
    -Construction Paper


  -Office Supplies
    -Glue
    -Paper Clips

接着剤とペーパー クリップは両方のカテゴリに割り当てられていることに注意してください。このカテゴリ ツリーでは 2 つの異なる場所に表示されますが、データベースでは同じカテゴリ ID を持っています。なんで？2 つの理由:

  1. カテゴリには属性が割り当てられます。たとえば、ペーパー クリップには、重量、素材、色などがあります。
  2. 接着剤カテゴリに割り当てられた製品は、美術工芸品および事務用品の下に表示されます。これは当然のことです。これらはデータベース内の実際のカテゴリ ID と同じです。

これにより、単一のカテゴリとその属性および割り当てられた製品を管理できますが、カテゴリ ツリー内の複数の場所に配置できます。

ネストされたセット モデルを使用しているため、これをサポートするために使用するデータベース構造は次のとおりです。

Category
----------
CategoryID
CategoryName


CategoryTree
------------
CategoryTreeID
CategoryID
Lft
Rgt

したがって、カテゴリ ツリー内に特定のカテゴリの複数のインスタンスが存在する可能性があるため、Category と CategoryTree の間には 1:M があります。

これをモデル化して、製品カテゴリを複数のカテゴリの下に表示できるようにする簡単な方法はありますか?

4

4 に答える 4

5

すべての接着剤が事務用品と手芸用品の両方に適していることが事実である限り、これに問題はないと思います。

于 2009-10-01T15:32:10.633 に答える
3

あなたが持っているのは良い方法ですが、2番目のテーブルを次のように単純化してみませんか?

カテゴリー

ID名

サブカテゴリ

ID カテゴリ ID サブカテゴリ ID

ただし、将来的には、2 つのルート カテゴリ間で子カテゴリを共有することに注意します。一貫性を保つために、製品の独自の分類を作成した方がよい場合があります。これにより、管理が容易になり、顧客がナビゲートしやすくなる可能性があります。それ以外の場合、事務用品からの Glue ページを表示している場合、他のパスも表示するという問題がありますか? そうでない場合は、SEO の問題であるパスを除いて、2 つの同一のページが表示されます。その場合、ユーザーは混乱する可能性があります。

于 2009-10-01T15:36:06.697 に答える
2

この最も有名な例は、分類がこのように行われるGoogleMailです。Googleは自社製品の使いやすさで有名です...

私は他の言葉が「親」の言葉よりも好ましいと信じています。それは実際にはXToOneの関係だけを示唆しています...

多分あなたはそれとProduct同じくらい多くと言うことができるCategoriesので、関係は多対多になるでしょう。そして、ディスプレイだけがカテゴリで始まり、製品に到達します...

これは問題を浮き彫りにします。カテゴリの数を制限せず、サブカテゴリなどでカテゴリを表示すると、次のようになる可能性があります。

  • 膨大なカテゴリと製品リスト、多くの重複があります
  • 大きな深さ（おそらく読めない）

興味深いのは、問題を浮き彫りにして、エンドユーザーにとって適切な解決策を想像することです。

于 2009-10-01T15:28:46.163 に答える
1

カテゴリが複数の親を持つことが必要になる場合もあります。ただし、カテゴリがどの親の下にあるかに関係なく、そのサブカテゴリは同じままである必要があります。

このロジックを正確に実装し、正常に動作する実際のシステムを見てきました。

編集

あなたの質問に答えるために、私が提案しているモデルはあなたが想像するほど制限的ではないと思います。基本的に、ツリーの特定のブランチは複数の親ブランチの下にある場合がありますが、見つかった場所には同じ子があります。これについては、あるブランチの一部の子を選択して別のブランチの子にすることを妨げるものは何もありません。

したがって、たとえば、事務用品とホビー用品の両方に接着剤のカテゴリを含めることができ、接着剤の下に「Crazy Glue (座薬版)」を追加すると、両方に表示されます. 論理的にはグループ化できるが、用途によって分離する必要があるアイテムがある場合でも、それを行うことができます。粘着剤とペーストは趣味の接着剤のカテゴリに入れることができますが、これは趣味のルートの下にはありますが、オフィスのルートの下にはありません。または、それを行うと同時に、バイヤーが内部で使用する結合されたカテゴリを作成することもできます。ビジネスモデルのオントロジーに属する場所に新しいタイプの接着剤を追加したら、関連するすべてのカテゴリにその新しいタイプの接着剤を含めることを忘れてはなりません。

要するに、この制限によって失うものはほとんどありませんが、各アイテムを個別に管理しなければならないという問題を回避するのに役立つ構造が少し得られます。

編集

モデル自体について説得力のあるケースを作成したと仮定すると、まだ実装の問題があります。多くのオプションがありますが、ここでは 1 つの方法を示します。

合成主キー、ラベル、オプションの説明/詳細テキスト、およびオプションの SKU (または同等のもの) を含む CatalogItem テーブルがあります。次に、子 ID と親 ID を持つ多対多の CatalogItemJoin があり、両側が CatalogItemTable に制限されています。

親として表示されるアイテムはカテゴリであるため、SKU はありません。子としてのみ表示されるアイテムは製品であるため、SKU が必要です。アイテムが複数の親を持つことは問題ありません。これは、複数のカテゴリに属していることを意味します。同様に、親ごとに複数の子があっても問題ありません。これは、少数の製品を含むカテゴリの典型的なケースです。ただし、カテゴリの ID が与えられた場合、どの親カテゴリが表示されたかに関係なく、その子は同じになります。もう 1 つの制約は、ループを回避することです。

于 2009-10-01T15:27:22.467 に答える