Что лучше.. левое внешнее соединение или правое внешнее соединение?

мы можем получить один и тот же результат обоими этими способами..

Table_1 LEFT OUTER JOIN Table_2

Table_2 RIGHT OUTER JOIN Table_1

Если мы можем получить тот же результат, зачем использовать правое внешнее соединение ? Какой из них лучше ?

5 ответов


как уже указывали другие LEFT OUTER JOIN и RIGHT OUTER JOIN - это точно такая же операция, за исключением обращенных аргументов. Ваш вопрос похож на вопрос, лучше ли писать a < b или b > a. Они одинаковые - это просто вопрос предпочтения.

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


они равны, просто вопрос предпочтения и читаемости. Я предполагаю, что это те же таблицы?


Левое Внешнее Соединение

результат левого внешнего соединения (или просто левого соединения) для таблиц A и B всегда содержит все записи "левой" таблицы (A), даже если условие соединения не находит никакой соответствующей записи в "правой" таблице (B). Это означает, что если предложение ON соответствует 0 (нулевым) записям в B, соединение все равно вернет строку в результате-но с NULL в каждом столбце из B. Это означает, что левое внешнее соединение возвращает все значения из левого стол, плюс совпадающие значения из правой таблицы (или NULL в случае отсутствия совпадающего предиката соединения)

Правое Внешнее Соединение

правое внешнее соединение (или правое соединение) близко напоминает левое внешнее соединение,за исключением обращения таблиц наоборот. каждая строка из" правой " таблицы (B) появится в объединенной таблице по крайней мере один раз. если нет совпадающей строки из" левой " таблицы (A), NULL будет отображаться в Столбцах из A для тех записей, которые не совпадают в B. правое внешнее соединение возвращает все значения из правой таблицы и совпадающие значения из левой таблицы (NULL в случае отсутствия совпадающего предиката соединения).

http://en.wikipedia.org/wiki/Join_%28SQL%29


дизайнеры языка SQL справедливо считали, что обеспечение приоритета слева направо соединений было бы ненужным ограничением на языке (к сожалению, они не чувствовали того же о порядке столбцов!)

кажется, что есть сильное предпочтение LEFT OUTER здесь, на Stackoverflow, в той степени, в которой люди изменят все соединение, чтобы иметь возможность использовать LEFT (у нас был один здесь только вчера).

говорят вы изначально написано в вашем запросе Table_2 INNER JOIN Table_1 прежде чем вы поняли, что вам действительно нужно внешнее соединение, сохраняющее все строки из Table_1. Было бы намного проще просто изменить INNER до RIGHT OUTER чем изменить целое соединение, чтобы иметь возможность использовать LEFT OUTER. Простой здесь хорош, потому что он менее инвазивен и, следовательно, меньше риска непреднамеренного изменения намерения запроса.

чтобы использовать другой аналогичный пример, рассмотрим оператор отношения semi join; часть реляционная алгебра, технология не может считаться относительно полной без нее. Хотя стандартный SQL имеет предикат semi join MATCH, он широко не реализован. Однако большинство продуктов SQL поддерживают различные обходные пути. Наиболее распространенным подходом в Stackoverflow является использование INNER JOIN СDISTINCT на SELECT предложение и исключение атрибутов из присоединенной таблицы. За этим следует использование WHERE table_1.ID IN (SELECT ID FROM Table_2). Следующий по популярности -WHERE EXISTS (SELECT * FROM Table_2 WHERE table_1.ID = table_1.ID).

дело в том, что все выше-это полу-соединения, которые очень часто встречаются в дикой природе. Хотя мое личное предпочтение использовать EXISTS (хотя любопытно, что он ближе к реляционному исчислению), мне все еще нужно уметь идентифицировать другие как полусоединения; интересно, что самый популярный подход (INNER JOIN плюс DISTINCT плюс не-проекция) может быть самым трудным для идентификации!

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

конечно, с точки зрения отношений, "правильный" ответ-полностью избегать внешних соединений. В реляционной модели нет такого понятия, как null, а внешние соединения явно предназначен для получения нулей.


Это зависит от нашей потребности - нужны ли нам все столбцы из левой таблицы или правой таблице.

оба не то же самое.