Как моделировать «товары» в приложении интернет-магазина - PullRequest
8 голосов
/ 03 апреля 2009

Я строю интернет-магазин по продаже таких товаров, как «Зеленые очень большие футболки». То есть одна и та же рубашка может иметь много размеров / цветов, разные комбинации могут быть распроданы, разные комбинации могут иметь разные цены и т. Д.

Мой вопрос заключается в том, как мне моделировать эти продукты в моем приложении 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

Таким образом, каждый продукт будет иметь одну или несколько характеристик (например, «Цвет», «Размер» и т. Д.), И каждая характеристика будет иметь один или несколько вариантов (например, «Красный», «Синий» и т. Д.).

Проблема с этим методом заключается в где хранить цены и запасы? Т.е. цена и запас данного товара определяются вариантами, которые принимают его характеристики. (Зеленый может быть дороже, чем красный, большой может отсутствовать на складе и т. Д.).

Одна мысль, которую я имел, состояла в том, чтобы дать продуктам "base_price" и позволить вариантам модифицировать его, но это кажется слишком сложным (и может не работать).

Ответы [ 2 ]

13 голосов
/ 03 апреля 2009

Я видел два решения этой проблемы. Первый - попытаться использовать признаки для определения подчиненных продуктов «основному» продукту. Проблема здесь заключается в том, что в дополнение к вашим мыслям, в большинстве случаев продукт будет развиваться вместе с новыми производителями, которые вносят новые аспекты. Например, один производитель может сделать более дешевый продукт, но иметь другой метод нанесения логотипа или шитья, который может быть достаточно значимым для отслеживания.

Я считаю, что лучше всего иметь несущественный номер продукта для каждого продукта и затем добавлять характеристики в качестве атрибутов. Это легко искать и расширять. Если группа продуктов тесно связана, группа продуктов, к которой относятся отдельные продукты, работает хорошо.

В таблицах:

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

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

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

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

            ...more attributes...

Преимущества здесь в том, что вы можете легко запрашивать определенные атрибуты, атрибуты являются «гибкими» в том смысле, что можно добавить больше (и старые, откорректированные: если вы начали с «Red», но затем добавили еще один «Red» к цвету) Вы можете изменить их на «Maroon» и «Bright Red».

Вы можете контролировать цену и запасы на уровне детализации продукта (хотя может потребоваться больше таблиц для учета источников затрат).

Все это предполагает, что ваши характеристики являются общими для всех. Если это не так, ваш подход к характерным подтаблицам может работать, создавая таблицу соединения между характеристиками и таблицами сведений о продукте и заполняя при необходимости. Для этого потребуется больше бизнес-логики. Чтобы каждая категория продукта получила все необходимых характеристик. В этом последнем случае я бы использовал «прототип» продуктов в таблице базовых продуктов (с Qty и Cost 0), из которого я бы клонировал характеристики и затем корректировал их при вводе каждого нового продукта. По мере перемещения вперед, когда появится новый вариант, было бы полезно иметь функцию «клонировать этот продукт», которая позволяет просто отрегулировать отличия от базового продукта.

Наконец, что касается управления запасами и ценообразованием, это произойдет на уровне пользовательского интерфейса. Возможность генерировать запросы для связанных продуктов (товарных групп) и управлять всеми ценами для связанных продуктов будет иметь большое значение для того, чтобы сделать это приемлемым.

2 голосов
/ 05 апреля 2009

Просто заметка. Вы всегда можете взглянуть на исходный код некоторых других продуктов электронной коммерции, таких как Spree и Substruct , которые, вероятно, уже ответили на этот вопрос для вас.

...