2010-01-19 13 views

risposta

19

È raro, ma ho alcuni casi in cui viene utilizzato. Tipicamente nei report delle eccezioni o ETL o in altre situazioni molto particolari in cui entrambe le parti hanno dati che si sta tentando di combinare. L'alternativa è usare un INNER JOIN, un LEFT JOIN (con il lato destro IS NULL) e un RIGHT JOIN (con il lato sinistro IS NULL) e fare un UNION - a volte questo approccio è migliore perché è possibile personalizzare ogni singolo join in modo più evidente (e aggiungi una colonna derivata per indicare quale lato è stato trovato o se è stato trovato in entrambi e quale vincerà).

+1

+1 per l'opzione alternativa :) –

9

Ho notato che la pagina di wikipedia provides an example.

Ad esempio, questo ci permette di vedere ogni dipendente che si trova in un reparto e ogni reparto che ha un dipendente, ma anche vedere ogni dipendente che non fa parte di un reparto e ogni reparto che non ha un dipendente .

Nota che non ho mai incontrato il bisogno di un full outer join in pratica ...

8

Ho usato esterno pieno si unisce quando si tenta di trovare i dati non corrispondenti, orfani, da entrambi i miei tavoli e voleva tutto il mio set di risultati, non solo le partite.

1

Le rare volte in cui l'ho usato ha riguardato il test dei valori NULL su entrambi i lati del join nel caso in cui ritengo che i dati mancanti nell'INNER JOIN iniziale siano utilizzati nell'SQL su cui sto eseguendo il test.

0

Sono utili per la ricerca di dati orfani, ma raramente li uso nel codice di produzione. Non sarei "sempre scoraggiato dall'usare uno" ma penso che nel mondo reale siano meno frequentemente la soluzione migliore rispetto agli interni e agli utenti di sinistra/destra.

0

Nei rari casi in cui ho utilizzato Full Outer Join era destinato a scopi di analisi dei dati, ad esempio quando si confrontano due tabelle clienti da diversi database per trovare duplicati in ogni tabella o per confrontare le due strutture di tabelle o per trovare valori nulli in una tabella rispetto all'altra o la ricerca di informazioni mancanti in una tabella rispetto all'altra.

0

Proprio oggi ho dovuto utilizzare Full Outer Join. È utile in situazioni in cui stai confrontando due tabelle. Ad esempio, le due tabelle che stavo confrontando erano da diversi sistemi così ho voluto ottenere le seguenti informazioni:

  1. tabella A ha tutte le righe che non sono nella Tabella B
  2. Tabella B ha tutte le righe che non sono in tabella a
  3. duplicati in entrambi tabella a o tabella B
  4. Per righe corrispondenti se i valori sono diversi (Esempio: La tabella a e tabella B hanno entrambi Acct # 12345, LoanID abc123, ma tasso di interesse o di importo del prestito è diversa

Inoltre, ho creato un campo aggiuntivo nell'istruzione SELECT che utilizza un'istruzione CASE per "commentare" perché sto segnalando questa riga. Esempio: Tasso di interesse non corrisponde/L'acct non esiste nel sistema A, ecc.

Quindi salvato come vista. Ora, posso usare questa vista per creare un report e inviarlo agli utenti per la correzione/immissione dei dati o usarlo per richiamare una popolazione specifica per il campo 'comment' che ho creato usando un'istruzione CASE (esempio: tutti i record con interessi non corrispondenti tariffe) nella mia stored procedure e automatizzare la correzione, ecc.

Se vuoi vedere un esempio, fammi sapere.

+0

Ecco perché le visualizzazioni riutilizzabili (al contrario di quelle con un solo utente e scopo espliciti) sono spesso scoraggiate! La gente mette cose del genere in una vista, poi qualcuno arriva e lo usa un sacco di volte con vari filtri. La prossima cosa che sai è che il sistema è ancorato e le persone si stanno chiedendo perché. Qualsiasi filtraggio scarta quasi inevitabilmente una o più delle 3 parti in un set di risultati (interno, sinistro o destro). Quando si utilizza Full, Query Optimizer non ha modo di scartare i join irrilevanti e quindi fa un sacco di lavoro extra solo per buttarlo via in un passaggio Filter. – bielawski

Problemi correlati