Quando o perché dovresti usare un join esterno destro anziché sinistro?

Question

Wikipedia afferma:

" In pratica, i join esterni a destra espliciti sono usati raramente, poiché possono sempre essere sostituiti con join esterni a sinistra e non offrono funzionalità aggiuntive. "

Qualcuno può fornire una situazione in cui ha preferito usare la notazione DESTRA, e perché? Non riesco a pensare a un motivo per usarlo mai. Per me, non renderebbe mai le cose più chiare.

Modifica: Sono un veterano di Oracle che sta facendo la Risoluzione del nuovo anno per svezzarmi dalla sintassi (+). Voglio farlo bene

Answer 1

L'unico motivo per cui riesco a pensare di utilizzare RIGHT OUTER JOIN è quello di provare a rendere il tuo SQL più auto-documentante.

È possibile che si desideri utilizzare i join di sinistra per le query che hanno righe null nel lato dipendente (molti) delle relazioni uno-a-molti e i join di destra su quelle query che generano righe null nel lato indipendente.

Ciò può verificarsi anche nel codice generato o se i requisiti di codifica di un negozio specificano l'ordine di dichiarazione delle tabelle nella clausola FROM.

Answer 2

Non ho mai usato right join prima e non ho mai pensato di poterne effettivamente avere bisogno, e sembra un po 'innaturale. Ma dopo averci pensato, potrebbe essere davvero utile nella situazione, quando devi unire all'esterno una tabella con l'intersezione di molte tabelle, quindi hai tabelle come questa:

E vuoi ottenere questo risultato:

Oppure, in SQL (MS SQL Server):

declare @temp_a table (id int)
declare @temp_b table (id int)
declare @temp_c table (id int)
declare @temp_d table (id int)

insert into @temp_a
select 1 union all
select 2 union all
select 3 union all
select 4

insert into @temp_b
select 2 union all
select 3 union all
select 5

insert into @temp_c
select 1 union all
select 2 union all
select 4

insert into @temp_d
select id from @temp_a
union
select id from @temp_b
union
select id from @temp_c

select *
from @temp_a as a
    inner join @temp_b as b on b.id = a.id
    inner join @temp_c as c on c.id = a.id
    right outer join @temp_d as d on d.id = a.id

id          id          id          id
----------- ----------- ----------- -----------
NULL        NULL        NULL        1
2           2           2           2
NULL        NULL        NULL        3
NULL        NULL        NULL        4
NULL        NULL        NULL        5

Quindi, se passi al join sinistro , i risultati non saranno gli stessi.

select *
from @temp_d as d
    left outer join @temp_a as a on a.id = d.id
    left outer join @temp_b as b on b.id = d.id
    left outer join @temp_c as c on c.id = d.id

id          id          id          id
----------- ----------- ----------- -----------
1           1           NULL        1
2           2           2           2
3           3           3           NULL
4           4           NULL        4
5           NULL        5           NULL

L'unico modo per farlo senza il giusto join è utilizzare l'espressione della tabella comune o la subquery

select *
from @temp_d as d
    left outer join (
        select *
        from @temp_a as a
            inner join @temp_b as b on b.id = a.id
            inner join @temp_c as c on c.id = a.id
    ) as q on ...

Answer 3

B RIGHT JOIN A è lo stesso di A LEFT JOIN B

B RIGHT JOIN A indica: B ON RIGHT, THEN JOIN A. indica che A si trova sul lato sinistro del set di dati. lo stesso di A LEFT JOIN B

Non ci sono prestazioni che si possono ottenere se si riorganizzano LEFT JOINs su RIGHT.

L'unico motivo per cui riesco a pensare al motivo per cui uno dovrebbe usare RIGHT JOIN è se sei un tipo di persona a cui piace pensare dall'interno verso l'esterno (seleziona * dal dettaglio nell'intestazione join destra). È come altri come little-endian, altri come big-endian, altri come design top down, altri come design bottom-up.

L'altro è se hai già una query enorme in cui vuoi aggiungere un'altra tabella, quando è un problema al collo riorganizzare la query, quindi basta collegare la tabella alla query esistente utilizzando RIGHT JOIN.

Answer 4

L'unica volta che vorrei pensare a un join esterno destro è se stavo riparando un join completo, ed è successo che ho avuto bisogno del risultato per contenere tutti i record dalla tabella a destra. Anche se sono pigro come me, probabilmente sarei così infastidito che lo riorganizzerei per usare un join sinistro.

Questo esempio tratto da Wikipedia mostra cosa intendo:

SELECT *  
FROM   employee 
   FULL OUTER JOIN department 
      ON employee.DepartmentID = department.DepartmentID

Se sostituisci semplicemente la parola FULL con RIGHT hai una nuova query, senza dover scambiare l'ordine della clausola ON .

Answer 5

SELECT * FROM table1 [BLANK] OUTER JOIN table2 ON table1.col = table2.col

Sostituisci [BLANK] con:

SINISTRA: se desideri tutti i record dalla tabella1 anche se non hanno un col che corrisponde alla tabella2 (inclusi anche i record della tabella2 con le corrispondenze)

DESTRA - se vuoi tutti i record da table2 anche se non hanno un col che corrisponde a table1 (anche inclusi sono record table1 con corrispondenze)

FULL: se si desidera tutti i record da table1 e da table2

Di cosa parlano tutti? Sono uguali? Non credo.

Answer 6

Le istruzioni SQL, oltre ad essere corrette, dovrebbero essere il più facili da leggere ed espressamente il più concise possibile (perché rappresentano singole azioni atomiche e la tua mente ha bisogno di grok completamente per evitare conseguenze indesiderate). A volte un'espressione è più dichiarato chiaramente con un join esterno destro.

Ma l'uno può sempre essere trasformato nell'altro e l'ottimizzatore farà altrettanto con l'uno.

Per un po ', almeno uno dei principali prodotti rdbms ha supportato solo LEFT OUTER JOIN. (Credo che sia stato MySQL.)

Answer 7

Le uniche volte in cui ho usato un join destro sono state quando volevo guardare due set di dati e ho già i join in un ordine specifico per il join interno o sinistro da una query precedentemente scritta. In questo caso, supponiamo di voler vedere come un set di dati i record non inclusi nella tabella a ma nella tabella b e in un altro set i record non nella tabella b ma nella tabella a. Anche allora tendo solo a fare questo per risparmiare tempo nella ricerca, ma lo cambierei se fosse il codice che verrebbe eseguito più di una volta.

Answer 8

SELECT * FROM table_a
INNER JOIN table_b ON ....
RIGHT JOIN table_c ON ....

In quale altro modo potresti unirti rapidamente / facilmente all'interno delle prime 2 tabelle e unirti a table_c assicurandoti che tutte le righe in table_c siano sempre selezionate?

Answer 9

In realtà non ho dovuto pensare molto al join giusto, ma suppongo che in quasi 20 anni non ho scritto una query SQL, ma ho trovato una valida giustificazione per usarne uno. Ne ho sicuramente viste molte che immagino derivino da dove gli sviluppatori hanno usato i compilatori di query integrati.

Ogni volta che ne ho incontrato uno, ho riscritto la query per eliminarla - ho scoperto che richiedono solo troppa energia mentale aggiuntiva per apprendere o riapprendere se non hai visitato la query per un po 'di tempo e non è raro che l'intenzione della query vada persa o restituisca risultati errati - ed è di solito questa erratezza che mi ha portato a chiedere di verificare perché le query non funzionavano.

Nel pensarci, una volta introdotto un join destro, ora hai quello che considererei rami della logica in competizione che devono incontrarsi nel mezzo. Se vengono introdotti requisiti / condizioni aggiuntivi, entrambi questi rami potrebbero essere ulteriormente estesi e ora hai più complessità che devi destreggiarti per garantire che un ramo non dia risultati errati.

Inoltre, una volta introdotto un join corretto, altri sviluppatori meno esperti che in seguito lavoreranno alla query potrebbero semplicemente imbullonare tabelle aggiuntive nella porzione di join destro della query e, in tal modo, espandere i flussi logici concorrenti che sono ancora necessari incontrarsi nel mezzo; o in alcuni casi che ho visto, iniziare a nidificare le visualizzazioni perché non vogliono toccare la logica originale, forse in parte, perché potrebbero non comprendere la query o le regole aziendali esistenti che hanno guidato la logica.

Answer 10

In alcuni database SQL, ci sono suggerimenti per l'ottimizzatore che indicano all'ottimizzatore di unire le tabelle nell'ordine in cui appaiono nella clausola FROM - ad es. / * + ORDERED * / in Oracle. In alcune semplici implementazioni, questo potrebbe anche essere l'unico piano di esecuzione disponibile.

In questi casi l'ordine delle tabelle nella clausola FROM è importante, pertanto RIGHT JOIN potrebbe essere utile.

Answer 11

Penso che sia difficile se in questo caso non hai diritto a partecipare. ex con oracolo.

with a as(
     select 1 id, 'a' name from dual union all
     select 2 id, 'b' name from dual union all
     select 3 id, 'c' name from dual union all
     select 4 id, 'd' name from dual union all
     select 5 id, 'e' name from dual union all
     select 6 id, 'f' name from dual 
), bx as(
   select 1 id, 'fa' f from dual union all
   select 3 id, 'fb' f from dual union all
   select 6 id, 'f' f from dual union all
   select 6 id, 'fc' f from dual 
)
select a.*, b.f, x.f
from a left join bx b on a.id = b.id
right join bx x on a.id = x.id
order by a.id