Wikipediastelt:
“In de praktijk worden expliciete rechter outer joins zelden gebruikt, omdat ze altijd kunnen worden vervangen door left outer joins en geen extra functionaliteit bieden.”
Kan iemand een situatie geven waarin hij de voorkeur heeft gegeven aan het gebruik van de JUISTE notatie, en waarom?
Ik kan geen reden bedenken om het ooit te gebruiken. Voor mij zou het de dingen nooit duidelijker maken.
Bewerken:
Ik ben een Oracle-veteraan die de nieuwjaarsresolutie maakt om mezelf te ontdoen van de (+) syntaxis. Ik wil het goed doen
Antwoord 1, autoriteit 100%
De enige reden die ik kan bedenken om RIGHT OUTER JOIN te gebruiken, is om te proberen je SQL meer zelfdocumenterend te maken.
Misschien wilt u linker-joins gebruiken voor query’s die null-rijen hebben in de afhankelijke (veel) kant van een-op-veel-relaties en rechter-joins voor die query’s die null-rijen genereren in de onafhankelijke kant.
Dit kan ook voorkomen in gegenereerde code of als de coderingsvereisten van een winkel de volgorde van declaratie van tabellen specificeren in de FROM-clausule.
Antwoord 2, autoriteit 55%
B RIGHT JOIN A is hetzelfde als A LEFT JOIN B
B RIGHT JOIN A luidt: B ON RIGHT, THEN JOINS A. betekent dat de A zich aan de linkerkant van de dataset bevindt. net hetzelfde als A LEFT JOIN B
Er zijn geen prestaties te behalen als u LEFT JOINs herschikt naar RIGHT.
De enige redenen die ik kan bedenken waarom je RIGHT JOIN zou gebruiken, is als je het type persoon bent dat graag van binnenuit denkt (selecteer * uit detail rechter join header). Het is net als anderen zoals little-endian, anderen zoals big-endian, anderen zoals top-down design, anderen zoals bottom-up design.
De andere is als je al een gigantische zoekopdracht hebt waarbij je nog een tabel wilt toevoegen, als het lastig is om de zoekopdracht opnieuw te rangschikken, dus sluit de tabel gewoon aan op de bestaande zoekopdracht met RIGHT JOIN.
Antwoord 3, autoriteit 52%
Ik heb nog nooit eerder RIGHT JOINgebruikt en had nooit gedacht dat ik het echt nodig zou hebben, en het lijkt een beetje onnatuurlijk. Maar nadat ik erover had nagedacht, zou het erg handig kunnen zijn in de situatie, wanneer je een tabel met een snijpunt van veel tabellen aan de buitenkant moet joinen, dus je hebt tabellen zoals deze:
En je wilt zo’n resultaat krijgen:
Of, 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
Dus als je overschakelt naar de left join, zullen de resultaten niet hetzelfde zijn.
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
De enige manier om dit te doen zonder de juiste join is door een algemene tabelexpressie of subquery te gebruiken
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 ...
Antwoord 4, autoriteit 23%
De enige keer dat ik aan een rechter outer join zou denken, is als ik een volledige join aan het repareren was, en het toeval wilde dat ik het resultaat nodig had om alle records uit de tabel aan de rechterkant te bevatten. Maar zelfs hoe lui ik ook ben, ik zou waarschijnlijk zo geïrriteerd raken dat ik het zou herschikken om een left join te gebruiken.
Dit voorbeeld van Wikipedialaat zien wat ik bedoel:
SELECT *
FROM employee
FULL OUTER JOIN department
ON employee.DepartmentID = department.DepartmentID
Als je het woord FULLvervangt door RIGHT, heb je een nieuwe zoekopdracht, zonder dat je de volgorde van de ON-clausule hoeft om te wisselen.
Antwoord 5, autoriteit 7%
SELECT * FROM table1 [BLANK] OUTER JOIN table2 ON table1.col = table2.col
Vervang [BLANK] door:
LINKS – als u alle records van tabel1 wilt, zelfs als ze geen col hebben die overeenkomt met die van tabel2 (ook inbegrepen zijn tabel2-records met overeenkomsten)
RECHTS – als u alle records van table2 wilt, zelfs als ze geen col hebben die overeenkomt met die van table1 (ook inbegrepen zijn table1-records met overeenkomsten)
VOL – als u alle records van tabel1 en van tabel2 wilt hebben
Waar heeft iedereen het over? Zijn ze hetzelfde? Ik denk het niet.
Antwoord 6, autoriteit 7%
SELECT * FROM table_a
INNER JOIN table_b ON ....
RIGHT JOIN table_c ON ....
Hoe kun je anders snel/gemakkelijk de eerste 2 tabellen samenvoegen en samenvoegen met table_c terwijl je ervoor zorgt dat alle rijen in table_c altijd zijn geselecteerd?
Antwoord 7, autoriteit 7%
Ik heb niet echt veel hoeven nadenken over de juiste join, maar ik veronderstel dat ik in bijna 20 jaar van het schrijven van SQL-query’s geen goede rechtvaardiging ben tegengekomen om er een te gebruiken. Ik heb er zeker veel van gezien waarvan ik vermoed dat ze voortkomen uit waar ontwikkelaars ingebouwde query-builders hebben gebruikt.
Telkens wanneer ik er een ben tegengekomen, heb ik de zoekopdracht herschreven om deze te elimineren – ik heb ontdekt dat ze gewoon te veel extra mentale energie vergen om te leren of opnieuw te leren als je de zoekopdracht een tijdje niet hebt bezocht en het is niet ongebruikelijk dat de bedoeling van de zoekopdracht verloren gaat of onjuiste resultaten oplevert – en het is meestal deze onjuistheid die heeft geleid tot verzoeken aan mij om te bekijken waarom de zoekopdrachten niet werkten.
Als je erover nadenkt, als je eenmaal een rechter-join hebt geïntroduceerd, heb je nu wat ik zou beschouwen als concurrerende takken van logica die elkaar in het midden moeten ontmoeten. Als er aanvullende eisen/voorwaarden worden geïntroduceerd, kunnen beide branches verder worden uitgebreid en heb je nu meer complexiteit waarmee je moet jongleren om ervoor te zorgen dat één branche geen aanleiding geeft tot onjuiste resultaten.
Bovendien, als u eenmaal een juiste join heeft geïntroduceerd, kunnen andere minder ervaren ontwikkelaars die later aan de query werken, eenvoudig extra tabellen toevoegen aan het rechtse join-gedeelte van de query en zo concurrerende logische stromen uitbreiden die nog steeds nodig zijn in het midden ontmoeten; of in sommige gevallen die ik heb gezien, beginnen met het nesten van weergaven omdat ze de oorspronkelijke logica niet willen aanraken, misschien gedeeltelijk, dit is omdat ze de vraag of de bedrijfsregels die de logica aanstuurden misschien niet begrijpen.
Antwoord 8, autoriteit 5%
SQL-statements moeten niet alleen correct zijn, ze moeten ook zo gemakkelijk te lezen en zo beknopt mogelijk zijn (omdat ze enkele atomaire acties vertegenwoordigen, en je geest moet ze volledig overhoop halen om onbedoelde gevolgen te voorkomen.) Soms is een uitdrukking meer duidelijk aangegeven met een rechter outer join.
Maar het ene kan altijd in het andere worden omgezet, en de optimizer doet het even goed met de een als met de ander.
Geruime tijd ondersteunde ten minste een van de belangrijkste rdbms-producten alleen LEFT OUTER JOIN. (Ik geloof dat het MySQL was.)
Antwoord 9, autoriteit 5%
De enige keren dat ik een rechter-join heb gebruikt, was wanneer ik naar twee sets gegevens wilde kijken en ik de joins al in een specifieke volgorde voor de linker- of inner-join van een eerder geschreven query had. Stel in dit geval dat u als een set gegevens de records wilt zien die niet in tabel a maar in tabel b zijn opgenomen en in een andere set de records niet in tabel b maar in tabel a. Zelfs dan heb ik de neiging om dit alleen te doen om tijd te besparen bij het doen van onderzoek, maar ik zou het veranderen als het code was die meer dan eens zou worden uitgevoerd.
Antwoord 10, autoriteit 2%
In sommige SQL-databases zijn er optimalisatiehints die de optimizer vertellen om de tabellen samen te voegen in de volgorde waarin ze verschijnen in de FROM-clausule – b.v. /*+ORDERED */in Orakel. In sommige eenvoudige implementaties kan dit zelfs het enige beschikbare uitvoeringsplan zijn.
In dergelijke gevallen is de volgorde van tabellen in de FROM-clausule van belang, dus RIGHT JOINkan nuttig zijn.
Antwoord 11
Ik denk dat het in dit geval moeilijk is als je niet over de juiste join beschikt. ex met orakel.
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