Многие ко многим через многих ко многим: есть ли необходимость в среднем соединении?

Question

Если упростить вопрос до его основ, у нас есть три таблицы компоненты , программы и пользователи , связанные во многих отношениях со многими промежуточнымитаблицы program_components и user_programs .

simplified table structure

users
- id (primary key)
- (...)

user_programs
- user_id (foreign key to users id)
- program_id (foreign key to programs id)

programs
- id (primary key)
- (...)

program_components
- program_id (foreign key to programs id)
- component_id (foreign key to components id)

components
- id (primary key)
- (...)

Мы интегрируем права пользователя на программные компоненты в нашей системе управления облаком.Я наткнулся на запрос со многими объединениями одно за другим, и мне было интересно, требуется ли средняя таблица или нет.

SELECT users.id, components.id FROM components
JOIN program_components ON c.id = program_components.component_id
JOIN programs ON program_components.program_id = programs.id
JOIN user_programs ON programs.id = user_programs.program_id
JOIN users ON user_programs.user_id = users.id
WHERE (...)

Требуется ли среднее соединение, или мы могли бы упростить это как

SELECT users.id, components.id FROM components
JOIN program_components ON c.id = program_components.component_id
JOIN user_programs ON program_components.programId = user_programs.programId
JOIN users ON user_programs.user_id = users.id
WHERE (...)

Из моих тестов они оба дают один и тот же набор данных, который я полностью ожидал.Вопрос больше в том, что MySQL ожидает получить, и какой запрос имеет смысл с точки зрения базы данных.

Для удобства чтения я бы посоветовал первую версию с дополнительным JOIN, поскольку он способствуетнамерение объединить несколько таблиц, проходя через общую таблицу Programs .Однако мне часто говорили, что слишком много объединений - это неправильный способ решения проблем. ^[1]

Есть ли какие-либо рекомендации в документах по таким запросам?

---

_{[1] Мы рефакторинг, чтобы включить правильную таблицу user_components, которая освободит нас от этих запросов и предоставит нам большую гибкость, но это выходит за рамки вопроса.}

Answer 1

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

При написании SQL-запросов всегда полезно проверять, сколько строк проверяется.Присоединяясь к таблице программ, вы должны просмотреть ее строку идентификатора, даже если вам не нужна какая-либо информация из нее.

Для получения дополнительной информации вам может быть интересно прочитать this , что объясняет некоторыеспособы повысить производительность ваших запросов