Изменение справочных данных и сохранение «истории»

Question

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

ID | имя | Цена

1. | Игрушечный автомобиль | 10 $
2. | Плюшевый медведь | 2 $

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

Solutions Я придумал это:

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

2. Другая идея - использовать механизм медленно изменяющихся размеров (от хранилища данных). Таблица каталогов требует дополнительных столбцов, таких как:

ID | имя | цена | версия

1. | Игрушечный автомобиль | 10 $ | 1

2. | Плюшевый медведь | 2 $ | 1

3. | Плюшевый медведь | 4 $ | 2

И таблица order_details со многими отношениями к таблице заказов и отношением «много-к-одному» с таблицей каталогов. В этом случае в таблице order_details содержится столько же строк, сколько меньше столбцов. Кон этим подходом является необходимость управления версиями продуктов.

Answer 1

Ответ на аналогичный вопрос - here, в котором обсуждается версия нормальной формы.

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

Answer 2

В целом ваш дизайн db зависит от логики вашего магазина. Но я могу предположить, что этот подход поможет вам:

Создать таблицу catalog_prices (priceId, productId, price, date) и в каталогов изменения таблицы price столбец priceId. Итак, каждый продукт будет иметь одну текущую цену, а таблица catalog_prices будет иметь историю цен на продукцию. Таким образом, запрос

SELECT c.ID, c.name, p.price FROM catalogs AS c 
INNER JOIN catalog_prices AS p ON c.priceId = p.priceId 

возвращает все продукты с ценами и запрос

SELECT c.ID, c.name, p.price, p.date FROM catalogs AS c 
INNER JOIN catalog_prices AS p ON c.ID = p.productId 

вернет всю историю цен.

Следующая в order_details Таблица добавить productPriceId column.Таким образом, запрос

SELECT d.ID, d.orderId, c.name, p.price FROM order_details AS d 
INNER JOIN catalog_prices AS p ON p.priceId = d.productPriceId 
INNER JOIN catalogs AS c ON p.productId = c.ID 

вернет детали заказа с ценами.

Это решение добавит дополнительное соединение для показа каталогов и заказанных продуктов, но позволяет уменьшить дублирование данных - цены будут храниться в одном месте. И вы сможете увидеть историю цен на продукт.