Должна ли таблица order_products быть денормализована?

Question

Таблица order_products содержит данные о товарах с указанием названия и цены товара. У него есть список записей о том, что покупатели купили.

Есть также два поля с именами product_name и price, которые являются дублирующими данными из таблицы products.

Стоит ли нормализовать таблицу order_products и создать таблицу истории (аудита) для названия продукта и цены? Тогда мне больше не нужны product_name и price в таблице order_products?

Answer 1

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

Я бы рассмотрел нормализованный подход, особенно если у вас есть много строк в order_products на (product name, price). Имейте дополнительную таблицу, которая хранит изменчивые состояния продукта каждый раз, когда они изменяются. Можно назвать product_history, как вы уже намекнули. Просто сохраните дату (или метку времени) с каждым новым состоянием. Для сохранения ссылочной целостности используйте ссылку на внешнюю ссылку на таблицу product. Как это:

create table product_history
(product_id    integer  -- or timestamp
,valid_from    date
,product_name  varchar
,price         decimal
,PRIMARY KEY (product_id, valid_from)
,FOREIGN KEY (product_id) REFERENCES product(product_id)
               ON DELETE CASCADE
               ON UPDATE CASCADE)

Быстрый запрос для поиска применимых изменчивых атрибутов:

SELECT *
FROM   product_history
WHERE  product_id = $my_product_id
AND    valid_from <= $my_date
ORDER  BY valid_from DESC
LIMIT  1;

Вам обязательно нужен индекс для (product_id, valid_from) , чтобы ускорить этот запрос. Первичный ключ в моем примере, вероятно, подойдет.

Answer 2

Невозможно сделать такое суждение, зная только структуру базы данных. Это зависит от того, как вы используете вашу базу данных (т.е. вставляет, выбирает, обновляет и удаляет ... И как часто?).

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

Полностью нормализованная база данных не оптимизирована для производительности. Вам часто приходится de нормализовать дизайн базы данных ..

Очень часто модель с определенной степенью избыточности данных является самой быстрой. При денормализации нужно просто следить за балансом между более быстрыми запросами и более медленными вставками / обновлениями!

Проверьте эти ответы, и, возможно, вы найдете дальнейшую помощь в принятии вашего решения! Когда денормализовать структуру базы данных

Answer 3

Да, это хорошая идея, но лучше создать одно поле в таблице order_products и вывести туда всю информацию о вашем заказе после их сериализации. При таком подходе вам не нужно создавать 2 новые таблицы (может быть больше, если вы хотите сделать то же самое для информации о подарочном купоне, информации о доставке и т. Д.)

Обоснование подхода заключается в том, что order_products размещаются в порядке, что означает, что они являются «опубликованными записями». Опубликованные записи не сильно меняются и не должны быть изменены. И эти записи должны храниться для будущих проверок.

Answer 4

Это зависит. Какова цель этой таблицы?

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

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