Подтвердить что ты не робот

Когда хорошая ситуация для использования полного внешнего соединения?

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

4b9b3361

Ответ 1

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

  • Таблица A имеет любые строки, которые не указаны в таблице B
  • Таблица B имеет любые строки, которые не указаны в таблице A
  • Дубликаты в таблице A или таблице B
  • Для сопоставления строк, отличны ли значения (пример: таблица A и таблица B имеют Acct # 12345, LoanID abc123, но процентная ставка или сумма займа отличаются

Кроме того, я создал дополнительное поле в инструкции SELECT, которое использует оператор CASE для комментариев, почему я помечен этой строкой. Пример: процентная ставка не соответствует /Acct не существует в системе A и т.д.

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

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