Когда стоит использовать полное внешнее соединение?

Question

Я всегда отговариваюсь от его использования, но есть ли обстоятельства, когда это лучший подход?

Answer 1

Это редко, но у меня есть несколько случаев, когда он используется. Обычно в отчетах об исключениях, ETL или других очень специфических ситуациях, когда обе стороны имеют данные, которые вы пытаетесь объединить.
Альтернативой является использование INNER JOIN, LEFT JOIN (с правой стороны IS NULL) и RIGHT JOIN (с левой стороны IS NULL) и выполнение UNION - иногда этот подход лучше, потому что вы можете более явно настраивайте каждое отдельное объединение (и добавьте производный столбец, чтобы указать, какая сторона найдена или будет ли она найдена в обеих и какая победит).

Answer 2

Я заметил, что страница википедии содержит пример .

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

Обратите внимание, что я никогда не сталкивался с необходимостью полного внешнего соединения на практике ...

Answer 3

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

Answer 4

Только сегодня мне пришлось использовать Full Outer Join. Это удобно в ситуациях, когда вы сравниваете две таблицы. Например, две таблицы, которые я сравнивал, были из разных систем, поэтому я хотел получить следующую информацию:

1. В таблице A есть строки, которых нет в таблице B
2. В таблице B есть строки, которых нет в таблице A
3. Дубликаты либо в таблице A, либо в таблице B
4. Для совпадающих строк, отличаются ли значения (Пример: и таблица A, и таблица B имеют Acct # 12345, LoanID abc123, но процентная ставка или сумма ссуды различаются

Кроме того, я создал дополнительное поле в операторе SELECT, которое использует оператор CASE, чтобы «прокомментировать», почему я помечаю эту строку. Пример: процентная ставка не совпадает / Акт не существует в системе A и т. Д.

Затем сохранил его как вид. Теперь я могу использовать это представление, чтобы либо создать отчет и отправить его пользователям для исправления / ввода данных, либо использовать его для извлечения определенной совокупности с помощью поля «комментарий», которое я создал с помощью оператора CASE (пример: все записи с несоответствующим интересом) ставки) в моей хранимой процедуре и автоматическом исправлении и т. д.

Если вы хотите увидеть пример, дайте мне знать.

Answer 5

Редкие случаи, когда я использовал его, были вокруг тестирования на NULL с обеих сторон объединения в случае, если я думаю, что данные отсутствуют в начальном INNER JOIN, используемом в SQL, на котором я тестирую.

Answer 6

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

Answer 7

Они удобны для поиска потерянных данных, но я редко использую их в производственном коде. Я не был бы "всегда отговаривать от использования одного" , но я думаю, что в реальном мире они реже являются лучшим решением по сравнению с внутренним и левым / правым наружным.