Как следует обращаться с данными по нескольким ценам на один продукт?

Question

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

Каждый товар может иметь следующие цены:

• Прайс-лист (MSRP)
• Стоимость (что мы платим за это)
• Розничная цена - отображается на «основном» сайте
• Правительственная цена (наш основной клиент - правительство США) - отображается только на нашем государственном поддомене
• Цена продажи (действительна в течение 1 месяца, но продлевается каждый месяц) - отображается только на нашем государственном поддомене
• Цена BPA (специальная цена для BPA) - не показана, но загружена на правительственные сайты

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

Я думаю, что лучший (только?) Порядок действий - это иметь отдельную таблицу с различной структурой цен, а также столбцы SaleStartDate и SaleEndDate, которые я могу проверить, чтобы увидеть, отображать или нет цена продажи. На самом деле, я не уверен ни в каком другом способе справиться с этим.

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

РЕДАКТИРОВАТЬ (17.02.2009 @ 12:57 PM): За исключением цены по прейскуранту, все цены рассчитываются на основе стоимости, однако это не всегда так просто; иногда цены на товары нужно менять вручную независимо от маржи, однако это выполняется вручную через Excel и только один раз в квартал (3 месяца); когда данные загружаются в базу данных, цена является конечной и не изменяется до следующего квартала; цена «продажи» действует вечно, но она истекает (не на нашем сайте, а на нескольких государственных сайтах, таких как GSA Advantage) и должна быть продлена; это не изменяется, хотя, когда это расширено. Цена продажи просто для того, чтобы наш собственный сайт был синхронизирован с GSA Advantage, поэтому, если правительственный клиент посещает наш сайт, он увидит те же цены, что и на Advantage.

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

РЕДАКТИРОВАТЬ (17.02.2009 @ 16:52): Некоторые очень хорошие идеи до сих пор. Одна из проблем заключается в том, что, кроме целей отчетности и ссылки, только одна из ценовых колонок является "реальной". Например, государственная цена всегда отображается для государственных заказчиков, но вместо этого отображается цена продажи, если текущая дата падает в течение даты продажи (цена «продажи» зависит от государственных клиентов). Если клиент заказывает BPA (это будет определено нашей системой обработки заказов и / или ручным переопределением пользователем), цена автоматически становится ценой BPA. Прайс-лист может отображаться для отображения скидки, которую вы получаете, и она требуется для отчетов, но больше ничего.

Кроме того, я не уверен в том, насколько плохо нормализующиеся вещи будут делать обновления. Прямо сейчас я только что передал электронную таблицу с новыми ценами и сказал обновить базу данных (так как все они находятся в таблице продуктов); Я делаю это на основе SKU продукта, поскольку идентификатор является только внутренним, а все связанные таблицы связаны через SKU. С отдельной таблицей цен это становится еще более громоздким, хотя я все еще мог бы использовать SKU в качестве ориентира (это будет уникальный индекс для продукта), но гораздо больше придется сделать вручную.

Answer 1

• Мой первый вопрос: могут ли все цены рассчитываются от одного из Цены? Если да и правила являются одни и те же продукты, мы находимся в несколько проще место.

• Изменились ли цены? независимо от других цен? Вы намекнули, что цена продажи действителен в течение 1 месяца, а затем продлен - цена остается прежней или это меняется? Если он останется прежним, это проще, чем если бы оно изменилось.

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

РЕДАКТИРОВАТЬ:

Я думал, что вы могли бы использовать постоянные вычисляемые столбцы для других цен, основанных на себестоимости, но, поскольку цены могут быть скорректированы вручную, это не вариант (я не верю, что вы может переопределить значения pcc). Вы можете написать хранимую процедуру для вставки начальных цен в таблицу PRICE на основе себестоимости.

На основании полученной информации, я думаю, что вам лучше всего было бы иметь отдельную таблицу PRICE из таблицы PRODUCT и внешний ключ product_id в таблице PRICE, ссылающейся на идентификатор первичного ключа PRODUCT стол -

Таблица ПРОДУКТОВ

id | name | image | description | etc... 

ЦЕНА стол

id | product_id | list_price | cost_price | retail_price | gov_price | sale_price | bpa_price | start_date | end_date

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

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

SELECT 
product.name,
price.list_price,
price.cost_price,
price.retail_price /*, ETC... */
FROM
product
INNER JOIN
price
ON product.id = price.product_id
WHERE
price.start_date <= @date
AND price.end_date >= @date

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

Чтобы справиться с другой ситуацией в компании, при условии наличия соответствующих разрешений и ограничений, я вижу несколько * проблем с хранением их цен в той же базе данных. Вы говорите, что они используют разную наценку - вы ссылаетесь на их цены? Если это так, вы можете обработать это с помощью company_id в таблице цен. Доступ к данным можно контролировать с помощью хранимых процедур и обновления цен с помощью транзакций.

* это зависит от того, насколько тесно связана работа между компаниями. Разрешено ли делиться ресурсами?

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

Answer 2

В MS SQL или Oracle:

Создать таблицу prices:

CREATE TABLE prices (product, pricetype, price, startdate, enddate)

Запрос:

SELECT product, price, pricetype
FROM (
  SELECT products.* ,
         prices.*
         ROW_NUMBER() OVER (PARTITION BY product, pricetype ORDER BY startdate) rn
  FROM products, prices
  WHERE prices.product = product.id
     AND startdate <= @date
 )
WHERE rn = 1
AND enddate >= @date

Это даст вам все цены всех типов, которые актуальны для данного @date

Answer 3

С моей точки зрения, я бы Таблица позиций: с ценой по прейскуранту (MSRP), стоимостью, розничной ценой, государственной ценой и ценой BPA

А

Таблица продаж: с продажной ценой, датой начала, датой окончания и, очевидно, ссылкой на таблицу товаров.

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

Только мои два цента.