Какой смысл в этом левом соединении? - PullRequest
Новая
       12

Какой смысл в этом левом соединении?

0 голосов
/ 05 июля 2018

Когда я использую BigQuery для запроса этих двух таблиц, кажется, что это левое соединение не имеет смысла. Он оставляет присоединение PD к PI на PD.STR_NBR = PI.STR_NBR, но затем фильтрует по PD.STR_NBR IS NULL. 

SELECT
      PI.CUST_ORD_NBR AS CUST_ORD_NBR,
      PI.STR_NBR AS STR_NBR,
      PI.SKU_NBR AS SKU_NBR
FROM
      PURCH_ITEM_ID PI
LEFT JOIN
      PROF_BID_DTL_W7 PD
   ON PD.CUST_ORD_NBR = PI.CUST_ORD_NBR
  AND PD.STR_NBR = PI.STR_NBR -- checks equality
  AND CAST(PD.SKU_NBR AS STRING) = PI.SKU_NBR
WHERE PD.STR_NBR IS NULL -- filters by null
;

Я не знаю, имеет ли это отношение, но я упомяну, что этот код BQ был перенесен с Teradata sql.

Ответы [ 2 ]

0 голосов
/ 05 июля 2018

Предположим, у вас есть две таблицы: farm и bank_savings, каждая таблица содержит данные обо всех таких живых лицах в США. Вы (сотрудник Департамента сельского хозяйства США), возможно, в основном интересуетесь пожилыми фермерами с низкими (> 10 000 долларов США и <20 000 долларов США) сберегательными счетами. Но вы также можете быть заинтересованы в других вещах, таких как (A) фермеры старше 65 лет с большими площадями или, возможно, (B) люди с низкими сберегательными счетами. </p>

Использование простого внутреннего JOIN (возможно, по номеру SS) дает вам первичную информацию, но не все вторичные данные (например, наборы данных A и B), представляющие интерес. Только для дополнительного набора данных A мы можем использовать LEFT JOIN. Только для дополнительного набора данных B мы можем использовать RIGHT JOIN. Для обоих наборов данных A и B мы используем FULL JOIN.

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

0 голосов
/ 05 июля 2018

Это дает вам все записи с комбинацией str_nbr, CUST_ORD_NBR и skus, которые присутствуют в PURCH_ITEM_ID, но не PROF_BID_DTL_W7

Редактировать: RToyo опубликовал хорошее объяснение в комментариях.

Просто для полноты. Возьми этот пример 

TableA

Key      Value
1        A
2        B
3        C

TableB
Key      Value
1        A
2        B

Предложение WHERE применяется к промежуточному набору результатов.

Так что, если я присоединюсь 

SELECT *
  FROM TableA A
  LEFT
  JOIN TableB B
    ON A.Key = B.Key
   AND A.Value = B.Value

Результат будет 

Key Value Key   Value 
1   A     1     A
2   B     2     B
3   C     NULL  NULL

Поскольку в {3, C} совпадений не найдено.

Так что, когда я добавляю в это, где условие 

SELECT TableA.*
  FROM TableA A
  LEFT
  JOIN TableB B
    ON A.Key = B.Key
   AND A.Value = B.Value
 WHERE B.Key IS NULL

Я только что получил последнюю запись 

Key Value 
3   C

Это логически (и чаще всего реализуется оптимизатором так же) эквивалентно 

SELECT TA.*
  FROM TableA TA
 WHERE NOT EXISTS
         ( SELECT 1
             FROM TableB TB
            WHERE TA.key = TB.key
              AND TA.value = TB.value
         );
...