Допустим, у меня есть таблица Products, и есть единица "по умолчанию", в которой продается продукт (скажем, EA для индивидуально). Продукт также доступен у некоторых поставщиков как BX (коробка) и CT (коробка), каждый из которых содержит определенное количество единицы «по умолчанию» (в нашем случае, скажем, коробка - 6, а коробка - 12). ,
У продукта есть обычная цена по прайс-листу, связанная с единицей «по умолчанию», а затем еще одна цена по прайс-листу для каждой из его дополнительных единиц продажи. Стоимость продукта (т. Е. То, что мы, как продавец, платим), различается в зависимости от продукта для каждого поставщика, и мы намереваемся реализовать способ просмотра списка поставщиков, продающих продукт, чтобы мы могли выбрать лучшую цену (например, мы могли бы пойти с поставщиком A для отдельного продукта, но Vendor B для коробки, потому что они продают его нам дешевле, чем Vendor A).
Бизнес-правила требуют, чтобы мы поддерживали отдельный SKU для продуктов на каждом уровне упаковки, но остальная информация (например, коммерческая копия, производитель, описание) идентична. Таким образом, для данного продукта с SKU ACM1234 он может иметь «отображаемые» SKU:
ACM1234 - Individual product (default) with List Price $5.00
ACM1234BX - Box packaging (6 individual) with List Price $28.00
ACM1234CT - Carton packaging (12 individual) with List Price $50.00
, и этот продукт может поставляться 3 поставщиками на разных уровнях - некоторые из них могут не поставлять коробочную версию, а поставлять коробку и одну упаковку, в то время как другие могут иметь все три.
Кроме того, продукт должен рассматриваться как отдельная единица, поскольку нашим основным клиентом является правительство США, и у нас есть понятие «контрактные» и «не контрактные» товары; Например, мы можем продавать правительству только коробочную и картонную версии продукта, но не единственную. Затем, когда мы получим заказ, нам нужно будет найти товар по его SKU (например, ACM1234BX) и получить обратно его информацию - например, для чего мы его продаем. Это может привести к проблемам, если в базе данных продукта есть «обычный» SKU (например, отдельный товар), но государственный заказчик приобрел коробочную версию.
Обычно у меня была бы «основная» таблица продуктов с SKU и другой соответствующей информацией, такой как описание. В таком случае, однако, каков будет лучший способ создать схему для обработки этого? Я мог бы сделать таблицу поиска некоторого вида и перечислить «общую» информацию в одной таблице (коммерческая копия, описание, переработано ли это и т. Д.) И связать ее с другой таблицей, в которой перечислены продукты и уровень их упаковки вместе с «вычисляемый» столбец с отображаемым SKU. Может быть что-то вроде:
# Products table
id description recycled sales copy
1 ACME(R) Widget Plus 1 The only Widget you will ever need...
# Packaging table
product_id unit selling_sku list_price
1 EA ACM1234 5.00
1 CT ACM1234CT 50.00
1 BX ACM1234BX 28.00
Но я боюсь, что это станет очень сложным и громоздким, когда дело доходит до поиска или добавления новых продуктов. Наши поставщики, от которых мы получаем фиды продуктов, содержат одну таблицу со всей соответствующей информацией и не предполагают, что вы продаете продукт в нескольких типах упаковки (только основной тип). Также они предоставляют свои собственные искусственные идентификаторы, которые связывают все вместе. Другой способ, которым я думал об этом, состоял в том, чтобы строка в таблице «Продукты» соответствовала обычному объекту продукта (например, один), а затем имела связанную таблицу с другими уровнями пакета для этого продукта и с пользовательским интерфейсом (который у меня нет). не задумываясь, пока я пытаюсь создать правильную модель данных) сделайте тип сделки с автоматическим предложением, при котором, если вы наберете ACM1234, он отобразит это вместе с вариантами BX и CT, и вы сможете выбрать один из них. вы хотите и получите соответствующие значения, заполненные им.
Мне кажется, что я на правильном пути, но я все еще думаю, что что-то упустил, и моя голова начинает кружиться от попыток мысленно запустить все эти потенциальные сценарии, чтобы найти масштабируемое решение. Он должен быть в состоянии разместить продукты, которые можно продавать по отдельности, в коробках и в коробках от разных поставщиков по разным ценам.
Есть предложения или мысли?
РЕДАКТИРОВАТЬ: Я использую SQL Server 2005 Standard в качестве базы данных.
РЕДАКТИРОВАТЬ (25/02/2009): Итак, следуя советам awithrow и David Aldridge что-то вроде:
# Products
id base_sku ...
1 ACM1234
# Vendors
id name
1 United Supply Co.
2 ACME Office Supply
# ProductsPackages
id productID unit listPrice
1 1 EA 5.00
2 1 BX 15.00
3 1 CT 40.00
# VendorsProductsPackages
vendorID packageID cost
1 1 3.45
1 2 7.85
1 3 14.86
2 2 10.45
Возможно, создайте таблицу, в которой будут отображаться суффиксы SKU для каждого типа юнита, если мы добавим больше.