Я разрабатываю базу данных для проекта веб-приложения, и я пришел к выводу, что у меня может быть несколько запросов, для которых потребуется много объединенных таблиц, чтобы сделать только одну проверку.Хранение «избыточных» внешних ключей во избежание присоединения
Мне интересно, как плохо хранить внешний ключ где-то на пути уменьшения количества объединений, необходимых для этих запросов?
Чтобы дать вам пример того, что я в данный момент: Сервис => Бронирование => сделка => Бумажник => BonusOffer
Мне нужно, чтобы проверить, была ли услуга была куплена с бумажником, связанного с бонус. Было бы разумно хранить BonusOffer id как внешний ключ транзакции?
Вы можете спросить, почему транзакция - это потому, что большинство этих запросов «пройдут». Транзакция и транзакция будут где-то посередине.
Мое сердце говорит, что вы не должны, но я думаю, вы можете попробовать, если хотите. Как всегда проверяйте «EXPLAIN PLAN», чтобы проверить, не улучшились ли вы. Потому что когда-то вы тратите много времени на то, чтобы оптимизировать что-то, что db уже разрабатывает для оптимизации, поэтому не нужно беспокоиться о «слишком большом» соединении –
@JuanCarlosOropeza, так же как и мое сердце! Я думал об использовании вспомогательных таблиц для связи между «BonusOffer» и «Transaction». Таким образом я бы избегал избыточности, и запрос был бы удовлетворен. Считаете ли вы, что это лучшая практика? На самом деле, я уверен, что эти запросы будут в любом случае быстрыми, но я хотел бы получить дополнительную информацию, прежде чем мне действительно нужно оптимизировать базу данных для производительности, а не делать это быстро, как только у меня возникнут проблемы с производительностью. – user1970395
Я не думаю, что это лучшая практика, потому что слишком усложняет что-то и будет снаружи. Это означает, что вам будет труднее работать, и вам нужно объяснить всем, кто стоит за вами, о ваших умных ярлыках. –