Этот вопрос является расширением еще один вопрос, который я задал относительно отношений «многие ко многим» в MySQL.
В настоящее время у меня есть 3 таблицы, которые мне нужно связать с 4-й промежуточной таблицей:
Stores, Products и States
Моя промежуточная таблица, _stores_products_states, объединяет id из трех других таблиц, чтобы определить, какой product продается, какой store и в каком state.
Теперь, насколько я понимаю, мне нужно было бы создать запись в _stores_products_states для каждой возможной комбинации из трех, правильно? Это привело бы к тысячам повторяющихся значений в 1-2 столбцах (но не во всех 3).
Например, если Лучший парень продает и GI Bros, и Дарби во всех 50 штатах, это будет 100 записей только для этих двух продуктов. Если эти продукты продаются в другом магазине, в них тоже будет 100 записей.
Это правильный способ реализовать такие отношения?
Обновлено: Вся эта настройка в основном предназначена только для определения доступности определенного продукта. Пользователь будет искать продукт и получать список магазинов, которые продают этот продукт в своем штате.
Это просто для определения наличия того или иного продукта. По сути, пользователь будет искать продукт, и список покажет, какие магазины продают этот продукт в своем штате (например, интернет-магазин, а не местное здание).
Это означает, что таблица, о которой вы спрашиваете, является бухгалтерской книгой, но вы заинтересованы в наличии продукта. Итак, если вам важна доступность продукта (продукт, комбинация магазинов), почему бы не создать таблицу product_availability, которая соединяет product и store через внешние ключи?
Потому что это не учитывает государство. Магазин может продавать один и тот же товар в нескольких штатах.






4-й стол - кстати! Так что, если я правильно понял, вашу таблицу _stores_products_states можно было бы даже назвать продажей
Не совсем. Это просто для определения наличия определенного продукта, а не для регистрации фактических продаж.
Нет необходимости создавать запись для всех комбинаций возможный продукта, состояния и магазина. Вам нужно только создать запись для комбинаций существующий, то есть наличия продукта в магазине в состоянии (возможно, с такими вещами, как местная цена и количество).
Вам так или иначе придется хранить эту информацию; таблица связей с тремя отношениями, особенно сохраненная как кластерный индекс MySQL, была бы довольно стандартным решением с хорошими характеристиками производительности.
Меня интересует, почему у вас есть магазины отдельно от состояний. Я ожидал, что магазин будет связан с государством. С помощью таблицы связи с тремя отношениями вы сможете связать один и тот же магазин с продуктом в нескольких разных состояниях. Это то, что предполагает ваша сфера деятельности?
Это верно. Согласно нашим реальным данным, магазин может продавать один и тот же товар в нескольких штатах, поэтому его нельзя связать только с одним государством.
Если значение комбинации
product_id, store_id, state_idтребуется для определения того, какой продукт, в каком магазине и в каком штате был продан, то у вас нет дублирования. Какая разница, если данные для двух столбцов будут содержать одни и те же данные? Вам нужно 3 части информации, вы сами сказали - 3 вместе взятые никогда не повторится. Вы не за горами, но вы можете продавать один и тот же товар в одном магазине несколько раз, верно? Что насчет этого дела? Вы просто увеличиваете количество в этом случае?