Possiamo ottenere lo stesso risultato in entrambi i modi ..Quale è meglio ... join esterno sinistro o join esterno destro?
Table_1 LEFT OUTER JOIN Table_2
Table_2 RIGHT OUTER JOIN Table_1
Se siamo in grado di ottenere lo stesso risultato perché utilizzare right outer join? Qual è il migliore ?
Come altri hanno fatto notare già LEFT OUTER JOIN e RIGHT OUTER JOIN sono esattamente la stessa operazione, se non con i loro argomenti invertiti. La tua domanda è come chiedere se è meglio scrivere a < b o b > a. Sono uguali: è solo una questione di preferenze.
Detto questo, trovo che molte persone hanno più familiarità con LEFT JOIN e lo usano in modo coerente nel loro SQL. Alcune persone trovano persino abbastanza difficile leggere se c'è improvvisamente un RIGHT JOIN nel mezzo di una query, e questo fa sì che debbano fermarsi e pensare a cosa significa. Quindi suggerirei che data una scelta uguale tra le due opzioni, preferisco usare LEFT JOIN. Essere coerenti renderà più semplice per gli sviluppatori capire il tuo SQL.
Questo è un esempio migliore di quello aggiunto nei commenti. Per qualche ragione, stavo disegnando uno spazio su un semplice operatore che non era simmetrico :-) –
Sì. Penso che la preferenza per LEFT derivi probabilmente dalla naturale inclinazione a iniziare a scrivere una query con le tabelle più "importanti", che spesso contengono informazioni complete, ovvero che non hanno righe mancanti e aggiungono tabelle che possono o non possono contenere informazioni correlate a quella. –
Questi sono uguali, solo una questione di preferenza e leggibilità. Presumo le sue stesse tabelle?
+1 e ti suggerisco di scegliere una preferenza e seguirla. Il risultato finale dovrebbe essere lo stesso se sei coerente nei tuoi join esterni. Ti suggerirei anche di usare i join esterni a sinistra se sei indeciso, solo perché molti altri lo fanno. – Dane
Dipende dal nostro bisogno: se abbiamo bisogno di tutte le colonne dalla tabella Left o dalla tabella Right.
Entrambi non sono uguali.
in entrambe le query otteniamo tutte le righe da Table_1 .. vale a dire lo stesso risultato .. BTW dovrebbe essere .. "se" :) – Vaibhav
LEFT OUTER JOIN
Il risultato di una join esterno sinistro (o semplicemente lasciato join) per la tabella A e B contiene sempre tutti i record della tabella "sinistra" (A), anche se il join- condizione non trova alcun record corrispondente nella tabella "destra" (B). Ciò significa che se la clausola ON corrisponde ai record 0 (zero) in B, il join restituirà comunque una riga nel risultato, ma con NULL in ogni colonna da B. Ciò significa che un join esterno sinistro restituisce tutti i valori dal tavolo, sinistra più valori dalla tabella di destra abbinato (o NULL in caso di non aderire corrispondenza predicato)
right outer join
un diritto outer join (o destra join) ricorda da vicino un join esterno sinistro , tranne che per il trattamento dei tavoli invertito. Ogni riga della tabella "destra" (B) verrà visualizzata almeno una volta nella tabella unita. Se non esiste una riga corrispondente dalla tabella "sinistra" (A), NULL verrà visualizzato in colonne da A per quei record che non hanno corrispondenza in B. Un join esterno destro restituisce tutti i valori dalla tabella di destra e i valori corrispondenti dal tabella sinistra (NULL in caso di nessun predicato di join corrispondente).
Sì, ma penso che la domanda che l'OP sta ponendo è se A LEFT OUTER JOIN B è lo stesso di B RIGHT OUTER JOIN A (notare le * tabelle * sono invertite e la direzione di join.) –
Volevo solo scrivere come funzionano perché poi si può capire che non sono diversi se li si usa come nel domanda ed è più informazioni utili. –
Grazie @ reader_1000 Ero in cerca di questa spiegazione :) – Jen
I progettisti del linguaggio SQL giustamente ritenuto che deve far valere sinistra a destra la precedenza di join sarebbe un vincolo inutile sulla lingua (purtroppo, non si sentivano lo stesso di colonna di ordinazione!)
ci fa sembra essere una forte preferenza per LEFT OUTER qui su Stackoverflow, nella misura in cui folk cambierà l'intero join solo per poter usare LEFT (ne abbiamo avuto uno here proprio ieri).
Supponiamo di aver scritto in origine nella query Table_2 INNER JOIN Table_1 prima di rendersi conto che è effettivamente necessario un join esterno che preservi tutte le righe da Table_1. Sarebbe molto più semplice cambiare lo INNER in RIGHT OUTER piuttosto che cambiare l'intero join per poter usare LEFT OUTER. Semplice è buono qui perché è meno invasivo e quindi meno il rischio che l'intento della query venga modificato inavvertitamente.
Per utilizzare un altro esempio simile, considerare l'operatore relazionale semi join; essendo parte dell'algebra relazionale, una tecnologia non può essere considerata come relazionalmente completa senza di essa. Sebbene SQL standard abbia un predicato semi join MATCH, non è ampiamente implementato. Tuttavia, la maggior parte dei prodotti SQL supporta vari metodi. L'approccio più comune visto su Stackoverflow sembra essere quello di utilizzare INNER JOIN con DISTINCT nella clausola SELECT e omettere gli attributi dalla tabella unita. Questo è seguito da vicino utilizzando WHERE table_1.ID IN (SELECT ID FROM Table_2). Il prossimo più popolare è WHERE EXISTS (SELECT * FROM Table_2 WHERE table_1.ID = table_1.ID).
Il punto è che tutti sopra sono semi-join che si trovano molto comunemente in natura. Sebbene la mia preferenza personale sia quella di usare EXISTS (sebbene curiosamente sia quella più vicina al calcolo relazionale), devo comunque essere in grado di identificare gli altri come semi-join; È interessante notare che l'approccio più popolare (INNER JOIN più DISTINCT più la non proiezione) può essere il più difficile da identificare!
refactoring per il solo scopo di di un raccordo stile personale è giustamente visto di buon occhio: costo di sforzi inutili, aumentano il rischio, implicazioni per il controllo di origine, ecc Imparare a riconoscere e rispettare gli altri preferenze è un'abilità importante: Se trovate te stesso refactoring una volta solo per essere in grado di capirlo ti metterà in una posizione di svantaggio.
Ovviamente, relazionalmente parlando, la risposta 'corretta' è quella di evitare integrazioni esterne del tutto. Non esiste nulla come null nel modello relazionale e i join esterni sono espressamente progettati per produrre valori nulli.
Per sommare 'a' e' b', puoi fare 'a + b' o' b + a'. Qual è il migliore? –
Penso che un moderno RDBMS possa trasformarsi l'uno con l'altro e scegliere quello che funziona meglio quindi non dovrebbe avere importanza. –