Вопрос о модели данных и времени

6yrop

Пусть у нас есть продукты, которые продаются. Цены на продукты меняются со временем.
Какая схема базы данных лучше?
1. У нас есть таблица Price, в которой цены периодически обновляются. При покупке цена копируется в таблицу Покупка.

2. Записи в таблице Price не обновляются, добавляются новые с указанием даты.

Наложить Foreign Key между таблицами Price и Покупка нельзя, поскольку Price.[date] это дата ввода цены, а Покупка.[date] это дата покупки.
Запрос для получения цены покупки будет выглядеть как-то так

SELECT *

FROM Price, Покупка

WHERE Price.product = Покупка.product AND

Price.[date] = (SELECT MAX([date])

		FROM Price

		WHERE Price.[date] < Покупка.[date]) AND

[Покупка].[id] = 1

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

Angelika_900

смотря какого размера таблица
пример:
торговоля оригинальными запчастями на ауди-фольксваген, прайс - 500.000 позиций, обновление - раз в квартал, цены меняются на все, 20% позиций меняются на новые
реально различных артикулов, которые продаются в течении года - 20.000
в таком случае лучше копировать цену

6yrop

480.000 записей, которые не связаны с Покупкой можно удалять после квартального обновления цен

Marikun

Типичная задача для аналитических систем. Называется slowly changing dimension. Использовал оба варианта. Выбор зависит от того, какую задачу надо решить.

6yrop

вообще у меня не аналитическая система, а обычна OLTP, и не "slowly changing"

ava3443

> Наложить Foreign Key между таблицами Price и Покупка нельзя, поскольку Price.[date] это дата ввода цены, а Покупка.[date] это дата покупки.
Вот тут не понял. Кто тебя заставляет делать foreign key по полю date? Например, можно связать поле id в таблице "price" (primary key) и поле price_id в таблице "покупка" (foreign key).

ava3443

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

6yrop

Вот тут не понял. Кто тебя заставляет делать foreign key по полю date? Например, можно связать поле id в таблице "price" (primary key) и поле price_id в таблице "покупка" (foreign key).

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

6yrop

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

поле date увеличивает эту таблицу всего на 20.000 записей в год. В этом подходе таблица Price растет вместе с таблицей Покупка.

Оставить комментарий