8

「グリーン 特大 Tシャツ」などの商品を販売するオンラインストアを構築しています。つまり、同じシャツでもサイズや色が異なる場合があり、組み合わせによって売り切れたり、組み合わせによって価格が異なる場合があります。

私の質問は、Rails アプリケーションでこれらの製品をどのようにモデル化する必要があるか (または、どのアプリケーションでどのようにモデル化するか) です。

私の現在の考えは次のとおりです。

Class Product
  has_many :variants, :through => :characteristics
  has_many :characteristics 
end

Class Characteristic
  belongs_to :product
  belongs_to :variants
end

Class Variant
  has_many :products, :through => :characteristics
  belongs_to :characteristic
end

したがって、各製品には 1 つ以上の特性 (「色」、「サイズ」など) があり、各特性には 1 つ以上のバリエーション (「赤」、「青」など) があります。

この方法の問題点は、価格と在庫をどこに保管するかということです。つまり、特定の製品の価格と在庫は、その特性が取るバリアントによって決定されます。（緑は赤よりも高価である可能性があり、大型は在庫がない可能性があるなど）.

私が考えた 1 つの考えは、製品に「base_price」を与え、バリエーションでそれを変更できるようにすることでしたが、これは非常に複雑に思えます (そしてうまくいかないかもしれません)。

4

2 に答える 2

13

この種のジレンマに対する 2 つの解決策を見てきました。1 つ目は、特性を使用して従属製品を「メイン」製品に定義しようとすることです。ここでの課題は、これまでの考えに加えて、ほとんどの場合、新しい側面をテーブルにもたらす新しいメーカーによって製品が進化することです. たとえば、あるメーカーはより安価な製品を製造しているかもしれませんが、追跡するのに十分重要なロゴやステッチの適用方法が異なる場合があります。

製品ごとに意味のない品番をつけて、その特徴を属性として付けるのが一番いいと思います。簡単に検索でき、拡張可能です。製品のグループが強く関連している場合、個々の製品が関連付けられている ProductGroup が適切に機能します。

表の場合:

            ProductGroup
            --------------------
            ProductGroupID
            ProductGroupName
            ProductGroupDescription

            Product
            --------------------
            ProductID
            ProductGroupID
            QtyOnHand
            BasePrice
            ProductColorID
            ProductSizeID

            ProductColor
            ------------
            ProductColorID
            ProductColorName

            ProductSize
            --------------
            ProductSizeID
            ProductSizeName

            ...more attributes...

ここでの利点は、特定の属性を簡単に照会できることです。属性は、さらに追加できるという点で「柔軟」です (また、古いものは調整されます。「赤」から始めて、別の「赤」をカラー プールに追加した場合、それらを「マルーン」と「ブライトレッド」に変更できます。

価格を制御でき、在庫は詳細な製品レベルにあります (ただし、調達コストを考慮するために、より多くのテーブルが必要になる場合があります)。

これはすべて、あなたの特徴が普遍的に共有されていることを前提としています. そうでない場合、特性サブテーブル アプローチは、特性と製品詳細テーブルの間に結合テーブルを作成し、必要に応じてデータを入力することで機能します。これには、各製品カテゴリが必要なすべての特性を確実に取得するために、より多くのビジネス ロジックが必要になります。この後者の場合、基本製品テーブル (Qty と Cost が 0) で「プロトタイプ」製品を使用し、そこから特性を複製してから、新しい製品が入力されるたびに調整します。進めていくうちに新しいバリエーションが出てきたときに、ベースとなる商品との違いだけを調整できる「この商品を複製」機能があると重宝します。

最後に、在庫と価格の管理に関する限り、これは UI レイヤーで行われます。関連製品 (製品グループ) のクエリを生成し、関連製品のすべての価格を管理できることは、これを住みやすくするのに大いに役立ちます。

于 2009-04-02T23:20:24.617 に答える