Более одного пути для присоединения к одной и той же таблице в Postgres

Question

Я унаследовал некоторые таблицы, которые я пытаюсь очистить, но сначала я пытаюсь объединить все, что мне нужно, но у меня возникают проблемы, потому что есть более одного способа добраться до таблицы SpecialEvents через EventRegistrations.

В некоторых случаях EventRegistrations можно соединить напрямую, используя event_registrations.scoreable_id, в то время как в других случаях вы должны сначала присоединиться к другой таблице SpecialPlaces, вы можете знать, каким путем вам нужно пройти через event_registrations.scoreable_type, чтолибо SpecialEvent, либо SpecialPlace.

В принципе, как я могу присоединиться к SpecialEvents в том случае, если я должен сначала присоединиться к SpecialPlaces?Например, если я пытаюсь присоединиться к SpecialEvents двумя различными способами, я получаю сообщение об ошибке: «имя таблицы« special_events »указано более одного раза».

SELECT event_registrations.id, array_agg(teams.name), event_registrations.number_of_players, event_registrations.state, event_registrations.created_at, array_agg(players.email), array_agg(special_events.name), array_agg(special_places.id)
FROM event_registrations
LEFT JOIN teams ON event_registrations.team_id = teams.id
LEFT JOIN team_memberships ON teams.id = team_memberships.team_id
LEFT JOIN players ON team_memberships.player_id = players.id
LEFT JOIN special_events ON event_registrations.scoreable_id = special_events.id AND event_registrations.scoreable_type = 'SpecialEvent'
LEFT JOIN special_places ON event_registrations.scoreable_id = special_places.id AND event_registrations.scoreable_type = 'SpecialPlace'
GROUP BY event_registrations.id, event_registrations.number_of_players, event_registrations.state, event_registrations.created_at

SpecialEvent

+----+-----------+---------------------------+-----------+---------------------------+
| id | region_id | start_at                  | state     | created_at                |
+----+-----------+---------------------------+-----------+---------------------------+
| 2  | 1         | 2015-10-22 19:30:00 +0100 | published | 2015-09-21 09:41:05 +0100 |
| 4  | 1         | 2016-01-21 19:30:00 +0000 | published | 2015-11-26 15:11:25 +0000 |
| 3  | 1         | 2016-01-28 19:30:00 +0000 | published | 2015-11-23 16:16:27 +0000 |
| 5  | 1         | 2016-12-31 19:30:00 +0000 | draft     | 2016-02-24 15:17:22 +0000 |
| 6  | 1         | 2016-05-16 19:30:00 +0100 | published | 2016-03-29 14:33:40 +0100 |
| 10 | 1         | 2016-09-12 19:30:00 +0100 | published | 2016-06-28 17:18:54 +0100 |
| 8  | 1         | 2016-10-07 19:30:00 +0100 | draft     | 2016-06-09 15:03:36 +0100 |
| 7  | 1         | 2016-05-23 19:30:00 +0100 | published | 2016-03-30 19:30:21 +0100 |
| 9  | 1         | 2016-08-04 19:30:00 +0100 | published | 2016-06-09 15:18:56 +0100 |
| 11 | 1         | 2016-11-07 19:30:00 +0000 | draft     | 2016-07-11 17:20:11 +0100 |
+----+-----------+---------------------------+-----------+---------------------------+

SpecialPlaces

+----+------------------+----------+---------------------------+
| id | special_event_id | place_id | created_at                |
+----+------------------+----------+---------------------------+
| 1  | 2                | 243      | 2015-10-12 18:07:09 +0100 |
| 3  | 2                | 83       | 2015-10-15 15:54:40 +0100 |
| 5  | 4                | 262      | 2015-11-26 16:29:35 +0000 |
| 4  | 3                | 262      | 2015-11-23 16:25:31 +0000 |
| 6  | 5                | 281      | 2016-02-24 15:20:33 +0000 |
| 7  | 6                | 262      | 2016-03-29 14:34:00 +0100 |
| 8  | 7                | 262      | 2016-04-11 13:28:00 +0100 |
| 9  | 8                | 262      | 2016-06-09 15:03:52 +0100 |
| 12 | 11               | 262      | 2016-07-11 17:20:26 +0100 |
| 10 | 9                | 262      | 2016-06-09 15:20:08 +0100 |
+----+------------------+----------+---------------------------+

Регистрация событий

+----+---------+--------------+----------------+-------+---------------------------+
| id | team_id | scoreable_id | scoreable_type | state | created_at                |
+----+---------+--------------+----------------+-------+---------------------------+
| 1  | 3979    | 2            | SpecialEvent   | draft | 2015-11-30 10:09:06 +0000 |
| 2  | 3717    | 2            | SpecialEvent   | draft | 2015-11-30 10:09:06 +0000 |
| 3  | 3626    | 8            | SpecialPlace   | draft | 2015-11-30 10:09:06 +0000 |
| 4  | 3202    | 8            | SpecialPlace   | draft | 2015-11-30 10:09:06 +0000 |
| 5  | 703     | 2            | SpecialEvent   | draft | 2015-11-30 10:09:06 +0000 |
| 6  | 278     | 2            | SpecialEvent   | draft | 2015-11-30 10:09:06 +0000 |
| 7  | 3166    | 2            | SpecialEvent   | draft | 2015-11-30 10:09:06 +0000 |
| 8  | 3147    | 2            | SpecialEvent   | draft | 2015-11-30 10:09:06 +0000 |
| 9  | 3146    | 2            | SpecialEvent   | draft | 2015-11-30 10:09:06 +0000 |
| 10 | 3145    | 2            | SpecialEvent   | draft | 2015-11-30 10:09:06 +0000 |
+----+---------+--------------+----------------+-------+---------------------------+

Answer 1

Что хотят сказать мои коллеги - это способ , вы хотите сделать это нереально, однако существует множество способов сделать то же самое.

Что бы вы могли сделать, чтобы избежать двух объединений, это создать объединенную таблицу из SpecialEvents и SpecialPlaces, содержащую всю необходимую вам информацию, а затем присоединиться к ней.

например, что-то вроде этого:

SELECT event_registrations.id, array_agg(teams.name), event_registrations.number_of_players, event_registrations.state, event_registrations.created_at, array_agg(players.email), array_agg(special_events.name), array_agg(special_places.id)
FROM event_registrations
LEFT JOIN teams ON event_registrations.team_id = teams.id
LEFT JOIN team_memberships ON teams.id = team_memberships.team_id
LEFT JOIN players ON team_memberships.player_id = players.id
LEFT JOIN special_places ON event_registrations.scoreable_id = special_places.id AND event_registrations.scoreable_type = 'SpecialPlace'
LEFT JOIN (
SELECT special_events.id AS special_event_id, special_places.id AS special_place_id, special_events.name
FROM special_places
LEFT JOIN special_events ON special_places.special_event_id = special_events.id
UNION
SELECT special_events.id AS special_event_id, null AS special_place_id, special_events.name
FROM special_events
) el1
ON (event_registrations.scoreable_id = el1.special_place_id AND event_registrations.scoreable_type = 'SpecialPlace') OR (event_registrations.scoreable_id = el1.special_event_id AND event_registrations.scoreable_type = 'SpecialEvent')
GROUP BY event_registrations.id, event_registrations.number_of_players, event_registrations.state, event_registrations.created_at

Answer 2

Предполагая , что id - это столбец PRIMARY KEY в каждой из приведенных таблиц и основываясь на некоторых догадках:

SELECT er.id
     , t.name  AS team_name            -- can only be 1, no array_agg
     , er.number_of_players
     , er.state
     , er.created_at
     , tp.player_emails                -- pre-aggregated!
     , se.name AS special_event_name   -- can only be 1, no array_agg
     , sp.id   AS special_pace_id      -- can only be 1, no array_agg
FROM   event_registrations   er
LEFT   JOIN teams t ON t.id = er.team_id
LEFT   JOIN (
   SELECT tm.team_id, array_agg(p.email) AS player_emails
   FROM   team_memberships tm
   JOIN   players          p  ON p.id = tm.player_id
   GROUP  BY 1
   ) tp USING (team_id)
LEFT   JOIN special_places sp ON sp.id = er.scoreable_id AND er.scoreable_type = 'SpecialPlace'
LEFT   JOIN special_events se ON se.id = er.scoreable_id AND er.scoreable_type = 'SpecialEvent'
                              OR se.id = sp.special_event_id AND er.scoreable_type = 'SpecialPlace'

Многое проще и быстрее.

Основные очки

• Если вам действительно нужно присоединиться к одному столу дважды, у вас будет использовать псевдонимы таблиц, такие как:

  FROM   event_registrations <b>er</b>

  , что означает:

  FROM   event_registrations <b>AS er</b>

  Оказывается, вам не необходимо присоединиться к одной и той же таблице дважды.Все еще используйте псевдонимы таблиц, чтобы уменьшить шум.Связанный:

  • Как объединить две таблицы, одна из которых не имеет первичного ключа и не имеет одинаковую длину символа
  • Запрос на ORDER BYколичество строк, возвращаемых из другого оператора SELECT

• Единственной определяемой причиной глобального GROUP BY во внешнем SELECT было соединение с team_memberships, котороепотенциально может умножить строки.Я переместил агрегацию player_emails в гораздо более дешевый подзапрос, удалил внешний GROUP BY и упростил остальное.Также должно быть существенно быстрее.Связанный:

  • Почему следующее объединение значительно увеличивает время запроса?
  • Объединение одного столбца в запросе с большим количеством столбцов

• Если вам нужно GROUP BY во внешнем запросе - а event_registrations.id действительно PRIMARY KEY - тогда это:

  GROUP  BY er.id, er.number_of_players, er.state, er.created_at
  

  ... это просто еще один шумный способ сказать:

  GROUP  BY er.id
  

  Начиная с Postgres 9.1, PK охватывает все столбцы таблицы в предложении GROUP BY.См .:

  • PostgreSQL - предложение GROUP BY

  Но вам это совсем не нужно.

• Наконец, основной вопрос решается путем присоединения сначала к условно special_places, а затем, снова условно, присоединения к special_events.Недостающие столбцы заполняются значениями NULL:

  LEFT   JOIN special_places sp ON sp.id = er.scoreable_id AND er.scoreable_type = 'SpecialPlace'
  LEFT   JOIN special_events se ON se.id = er.scoreable_id AND er.scoreable_type = 'SpecialEvent'
                                OR se.id = sp.special_event_id AND er.scoreable_type = 'SpecialPlace'
  

  Конечный AND er.scoreable_type = 'SpecialPlace', строго говоря, является избыточным, поскольку в любом случае sp.special_event_id не может быть иначе.Я сохранил это для ясности.

Answer 3

Говоря математически, порядок не влияет на ваш результат (он влияет на эффективность).

Сказав это, многие реализации СУБД (Postgres) имеют функции, которые выбирают наименее затратный порядок соединения.

Если вы хотите применить определенный порядок соединения (даже если он дает вам тот же ответ), вы можете использовать скобки. Даже в этом случае я не уверен, что оптимизатор запросов не переписывает ваше дерево запросов для оптимизации производительности - изменяя порядок соединения.