Вопрос проектирования базы данных в приложении электронной коммерции - PullRequest
3 голосов
/ 22 октября 2010

Я создаю базу данных для электронной коммерции ... Мне бы хотелось предложить следующий вариант:

  • Продукт может иметь несколько размеров и несколько цветов
  • Каждая комбинацияРазмер / цвет товара должен иметь определенную цену

Итак, у меня может быть Продукт X с размерами: A, B, C и цветами: Зеленый, Черный и Белый

И каждая комбинация имеет свою цену ...

Она реализована в Amazon, один пример здесь: http://www.amazon.com/Champion-Mens-Jersey-Black-Large/dp/B0010EEYCU/ref=sr_1_4?ie=UTF8&s=sporting-goods&qid=1287767784&sr=1-4

Мне нужна помощь в разработке этого!

РЕДАКТИРОВАТЬ: Продукт может иметь цену без размера и цвета

Спасибо

Ответы [ 4 ]

7 голосов
/ 22 октября 2010

Среди многих способов подойти к этому я бы выделил:

  1. Имеется отдельная запись Product для каждой комбинации цвета / размера каждого элемента. У каждого своя цена.
  2. Если многие элементы имеют одинаковые размеры и цвета (например, если вы продаете рубашки и каждая рубашка доступна в любом из пяти размеров и трех цветов), может иметь смысл нормализовать Size и Colour в свои собственные таблицы и имеют таблицу PricePoint, которая объединяет их все вместе - каждая комбинация элемента, цвета и размера имеет запись в PricePoint с соответствующей ценой.

Обратите внимание, что второй подход, хотя и более нормализованный, может вызвать проблемы при отслеживании товаров / запасов. Поскольку легче отслеживать отдельные товары, если у каждого товара в каждой ценовой категории есть свой собственный SKU (или другой общий идентификатор), вы можете предпочесть смешанный подход:

  • Таблица Product, которая будет содержать запись для каждой комбинации элемента, размера и цвета, с уникальным SKU и ценой для каждой.
  • Таблица Size, которая нормализует общие размеры, которые могут иметь ваши Продукты. Product имеет внешний ключ к этой таблице.
  • A Colour таблица, как указано выше.
  • A ProductType или ProductGrouping, которая определяет расширенные наборы продуктов для упрощения организации / поиска. Каждый продукт будет иметь внешний ключ к этой таблице «родительский продукт». Например, у вас может быть ProductType = 'Футболка', с которой связано несколько десятков Продуктов - по одному Продукту для каждой комбинации стиля, размера и цвета рубашки.

Обновление: Для уточнения таблицы "superset", согласно запросу OP, я бы расширил пример @Phil Sandler следующим образом:

Добавить таблицу группы продуктов:

Product Group (defines a superset of similar products that will be grouped or filtered together)
product_group_id
product_group_name

И отредактируйте таблицу Product, чтобы добавить внешний ключ в группу продуктов:

Product Table (defines the product):
product_id
product_group_id
product_name

Теперь, чтобы выделить примерную комбинацию в определенной ценовой категории, приведем некоторые готовые данные:

Товар: product_id = 100, product_group_id = 1, product_name = 'Мужская футболка с круглым вырезом'

Группа продуктов: product_group_id = 1, product_group_name = 'Футболки'

Цвет: product_color_id = 10, product_id = 100, color_id = 6 Предположим, «6» - «Синий». Эта запись означает, что T с круглым вырезом доступен в синем

Размер: product_size_id = 11, product_id = 100, size_id = 2 Предположим, что «2» означает «Средний». Эта запись означает, что T с круглым вырезом доступен в среднем

Цена: product_price_id = 555, product_id = 100, product_size_id = 11, product_color_id = 10, цена = 24.99 * Эта запись означает, что средняя синяя футболка с круглым вырезом стоит 24,99 доллара (обратите внимание на значение price_id, отсутствующее в примере Фила) *

Таблица групп продуктов, используя этот пример, позволит вам выполнять запросы по всей линейке продуктов, например «Выбрать самую дорогую большую футболку, которую мы продаем».

6 голосов
/ 02 февраля 2011

Извините за поздний ответ, но я только что натолкнулся на этот вопрос и решил добавить свой метод.Во-первых, позвольте мне сказать, что цвет / размер / стиль весьма специфичны для индустрии моды.Раньше я работал в компании, которая занималась разработкой программного обеспечения для управления запасами, и они не стали его трогать !!

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

Мой метод более сложен на заднем конце, но позволяет значительно быстрее генерировать единицы хранения запасов и неограниченные возможности.

Так:

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

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

Таким образом, если запись 1 в вашей таблице «options» имеет значение «size», то записи для «small», «medium» и т. Д. Будут связаны с этой записью.

Таким образом, вы можете настроить параметры, доступные для выбора во всех продуктах.

В качестве отступления: вы можете сделать жизнь еще проще, создав таблицу 'optionsGroup' - которая будетиспользуется для связи обеих таблиц вместе.Поэтому, если ваш ассортимент футболок доступен в красном, зеленом, черном и белом цветах, вы можете назначить эти параметры для параметров «цвет» группы «футболки».Тогда ваши джамперы могут быть красного, синего, желтого, серого цвета, поэтому вы можете связать их с группой «Толстовки».Таким образом, значения параметров цвета по-прежнему связаны с параметром цвета, но только соответствующие значения будут отображаться на каждой странице продукта в вашей системе администрирования.

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

Так что для продукта с футболкой теперь у вас будет отдельная запись для каждого варианта продукта, доступного для продукта.

Теперь действительноумный бит: вы пишете запрос, который просматривает каждую доступную опцию и возвращает каждую возможную комбинацию их всех - создавая каждую как отдельную запись SKU!Каждая из этих записей может содержать отдельные модификаторы цен, изображения, что угодно, и что более важно, вы можете просто деактивировать любые комбинации, которые не будут работать для вас.

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

2 голосов
/ 26 октября 2010

Стандартный подход заключается в том, чтобы рассматривать продукт и SKU как отдельные вещи. SKU имеет определенный размер, цвет и цену, а продукт представляет собой семейство связанных SKU.

create table product (
  product_id integer primary key,
  name varchar(255) not null,
  description varchar(2048) not null
);

create table sku (
  sku_id integer primary key,
  product_id integer references product,
  size varchar(40),
  colour varchar(40),
  price numeric(8, 2) not null,
);

Вы можете нормализовать цвет и размер, сделав поля в SKU ссылками на строки в таблицах цветов и размеров, а не на текст произвольной формы. Вы также можете разделить цены, чтобы вы могли делать такие вещи, как цены на разные даты, цены со скидкой и т. Д.

Обычно вы строите свой сайт вокруг продуктов и отображаете ассортимент SKU в виде одной из деталей, в виде таблицы или раскрывающегося списка или чего-то еще на странице продукта.

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

2 голосов
/ 22 октября 2010

Один возможный дизайн:

Product Table (defines the product):
product_id
product_name

Product Size Table (defined valid sizes for the product):
product_size_id
product_id
size_id (assuming here that you have a lookup table for generic sizes like S/M/L/XL)

Product Color Table (defines valid colors for the product):
product_color_id
product_id
color_id (again, assuming there is a lookup for Blue/Green/Purple/etc.)

Product Price Table (applies a price to the product/size/color combination):
product_price_id
product_size_id
product_color_id
price
...