Проектирование базы данных - Хранение исторической информации внешнего ключа - PullRequest
0 голосов
/ 05 февраля 2019

Допустим, у меня есть интернет-магазин (не настоящий случай, но достаточно близкий).У меня есть товары и товарные категории.Каждый товар относится только к одной категории, но есть возможность переместить товар из категории в другую.Также есть покупка, которая содержит ссылку на товар, а также дату покупки.Для упрощения есть только один предмет на покупку.

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

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

Я рассмотрел два решения, но я не очень удовлетворен ни одним из них.

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

Есть ли какой-то другой вариант, о котором я не подумал?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...