Каков наилучший способ сохранить исторический прайс-лист в таблице MySQL?

Question

По сути, мой вопрос таков: у меня есть список цен, некоторые из которых являются историческими (то есть я хочу, чтобы поиск этого продукта X составлял 0,99 долл. 11 марта, 1,99 долл. 1 апреля и т. Д.) , Каков наилучший способ хранения этой информации?

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

CREATE TABLE prices (
         id BIGINT auto_increment not null,
         primary key (id),
         price DECIMAL(4,2) not null,
         effectiveStartDate DATETIME NOT NULL,
         effectiveEndDate DATETIME 
);

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

Answer 1

Отделите потребность в исторических данных от потребности в текущей цене. Это значит:

1) Сохранить текущую цену в таблице продуктов.

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

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

Answer 2

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

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

Answer 3

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

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

Я бы также дважды проверил вашу платформу / язык / фреймворк / стиль работы, прежде чем опускать пользовательский первичный ключ "id" в пользу [product_id, start_date, ..? ..] составного пакета. Последний вариант несколько более логичен (по крайней мере, я лично предпочитаю его), но иногда он может иметь неприятные последствия, например, если ваша библиотека БД имеет ограниченный способ работы с более сложными первичными ключами.