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

Допустим, у меня есть Products таблица, и есть единица "по умолчанию", в которой продается продукт ( EA скажем, индивидуально). Продукт также доступен от некоторых поставщиков в виде BX (коробка) и CT (коробка), каждый из которых содержит определенное количество единиц «по умолчанию» (в нашем случае допустим, что в коробке 6 штук, а в коробке 12).

У продукта есть обычная прейскурантная цена, связанная с единицей "по умолчанию", а затем другая прейскурантная цена для каждой из дополнительных единиц продажи. Стоимость продукта (то есть то, что мы, как продавец, платим) различается в зависимости от продукта в зависимости от поставщика, и мы намерены реализовать способ просмотра списка продавцов, продающих продукт, чтобы мы могли выбрать лучшую цену (например, мы могли бы пойти с поставщиком A для отдельного продукта, но поставщик B для коробки, потому что они продают его нам дешевле, чем поставщик A).

Бизнес-правила требуют, чтобы мы поддерживали отдельные артикулы для продуктов на каждом уровне упаковки, но остальная информация (например, торговая копия, производитель, описание) идентична. Таким образом, для продукта с артикулом ACM1234 могут быть «отображаемые» артикулы:

ACM1234 - Отдельный продукт (по умолчанию) с прейскурантной ценой $ 5,00
ACM1234BX - Коробочная упаковка (6 шт.) По прейскурантной цене $ 28.00
ACM1234CT - Картонная упаковка (12 шт.) По прейскурантной цене $ 50.00

и этот продукт может поставляться 3 поставщиками на разных уровнях - некоторые из них могут поставлять не картонную версию, а коробочную и отдельную, в то время как другие могут поставлять все три.

Кроме того, продукт необходимо рассматривать как отдельную организацию, поскольку нашим основным покупателем является правительство США, и у нас есть понятие «контрактных» и «неконтрактных» продуктов; например, мы могли бы продать правительству только коробочную и картонную версии продукта, но не единственную. Когда мы получим заказ, нам нужно будет найти товар по его артикулу (например ACM1234BX ) и получить обратно информацию о нем - например, за что мы его продаем. Это может вызвать проблемы, если в базе данных продуктов есть «обычный» артикул (например, единичный товар), но государственный заказчик приобрел коробочную версию.

Обычно у меня есть «основная» таблица продуктов, в которой есть артикул и другая соответствующая информация, например описание. Однако в таком случае, как лучше всего создать схему для решения этой проблемы? Я мог бы сделать какую-то таблицу поиска и перечислить «общую» информацию в одной таблице (коммерческая копия, описание, переработана ли она и т. Д.) И связать ее с другой таблицей, в которой перечислены продукты и уровень их упаковки вместе с "вычисляемый" столбец с отображаемым артикулом. Может быть что-то вроде:

# Таблица товаров
ID описание переработанная коммерческая копия
1 ACME (R) Widget Plus 1 Единственный виджет, который вам когда-либо понадобится ...

# Упаковочный стол
product_id unit sales_sku list_price
1 EA ACM1234 5.00
1 ТТ ACM1234CT 50.00
1 BX ACM1234BX 28.00

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

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

Есть предложения или мысли?

РЕДАКТИРОВАТЬ: я использую SQL Server 2005 Standard в качестве базы данных.

РЕДАКТИРОВАТЬ (25.02.2009): Итак, следуя совету awithrow и David Aldridge чему-то вроде:

# Продукты
id base_sku ...
1 ACM1234

# Продавцы
имя id
1 United Supply Co.
2 Канцелярские товары ACME

# ProductsPackages
id productID unit listPrice
1 1 EA 5.00               
2 1 BX 15.00
3 1 CT 40.00

# VendorsProductsPackages
vendorID packageID стоимость          
1 1 3,45          
1 2 7,85
1 3 14,86
2 2 10,45

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

Ответов (2)

Решение

Похоже, вы на правильном пути, но похоже, что ваши столы нужно еще немного разбить. Вот как бы я это сделал:

Таблица товаров похожа на ту, что у вас есть:

Products table

id    description             recycled  base_SKU     sales_copy
1     ACME(R) Widget Plus     1         ACM1243      The only Widget you will ever need...

Стол для упаковки

Packaging table:

id     unit     SKU_suffix
1      EA       ''
2      CT       'CT'
3      BX       'BX'

Наконец, третья таблица, которая связывает эти два:

Packaged Product Table

id     product_id     package_id     price
1      1              1              $5
2      1              2              $50
3      1              3              $28

Теперь вы можете выбрать из третьей таблицы и использовать base_SKU и SKU_suffix для создания «окончательного» SKU. Это будет зависеть от того, какой движок БД вы используете. Этот идеал заключается в том, что он предотвращает копирование одной и той же информации в несколько таблиц.

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

SELECT <fields> from Packaged_Products WHERE package_id != 1

опять же, это будет зависеть от вашей БД

надеюсь это поможет

Мне кажется, вам понадобятся следующие таблицы:

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