sql - right - ¿Cuándo o por qué usarías una combinación externa derecha en lugar de izquierda?

right join sql server ejemplos

Question

Wikipedia dice:

"En la práctica, las combinaciones externas derechas explícitas rara vez se utilizan, ya que siempre se pueden reemplazar con combinaciones externas izquierdas y no proporcionan ninguna funcionalidad adicional".

¿Puede alguien proporcionar una situación en la que hayan preferido usar la notación RIGHT y por qué? No puedo pensar en una razón para usarlo alguna vez. Para mí, nunca dejaría las cosas más claras.

Editar: Soy un veterano de Oracle que hace la Resolución de Año Nuevo para destetarme de la sintaxis (+). Quiero hacerlo bien

Answer 1

B RIGHT JOIN A es lo mismo que A LEFT JOIN B

B RIGHT JOIN A lee: B ON RIGHT, LUEGO se une a A. significa que A está en el lado izquierdo del conjunto de datos. al igual que A IZQUIERDA ÚNETE B

No hay rendimiento que pueda obtenerse si reorganiza IZQUIERDA A DERECHA.

Las únicas razones por las que puedo pensar por qué se usaría RIGHT JOIN es si eres del tipo de persona a la que le gusta pensar desde adentro hacia afuera (selecciona * del detalle right join header). Es como otros como little-endian, otros como big-endian, otros como diseño de arriba hacia abajo, otros como diseño bottom up.

La otra es si ya tiene una consulta enorme en la que desea agregar otra tabla, cuando es una molestia para reorganizar la consulta, de modo que simplemente conecte la tabla a la consulta existente utilizando DERECHO A UNIRSE.

Answer 2

Creo que es difícil si no tienes derecho de unirse en este caso. ex con oráculo

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

Answer 3

En algunas bases de datos SQL, hay sugerencias de optimizador que le dicen al optimizador que una las tablas en el orden en que aparecen en la cláusula FROM , por ejemplo, /*+ORDERED */ en Oracle. En algunas implementaciones simples, este podría ser el único plan de ejecución disponible.

En tales casos, el orden de las tablas en la cláusula FROM importante, de modo que RIGHT JOIN podría ser útil.

Answer 4

La única razón por la que se me ocurre usar RIGHT OUTER JOIN es intentar que tu SQL sea más autodocumentado.

Es posible que desee utilizar combinaciones a la izquierda para consultas que tienen filas nulas en el lado dependiente (muchos) de las relaciones uno a varios y uniones a la derecha en aquellas consultas que generan filas nulas en el lado independiente.

Esto también puede ocurrir en el código generado o si los requisitos de codificación de una tienda especifican el orden de declaración de las tablas en la cláusula FROM.

Answer 5

La única vez que pensaría en una combinación externa correcta es si estuviera arreglando una combinación completa, y simplemente sucedió que necesitaba el resultado para contener todos los registros de la tabla de la derecha. Sin embargo, aunque soy tan flojo como yo, probablemente me enojaría tanto que lo reorganizaría para usar una combinación izquierda.

Este ejemplo de Wikipedia muestra lo que quiero decir:

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

Si simplemente reemplaza la palabra FULL con la RIGHT , tiene una nueva consulta, sin tener que cambiar el orden de la cláusula ON .

Answer 6

Las únicas veces que he usado una unión correcta han sido cuando quiero ver dos conjuntos de datos y ya tengo las uniones en un orden específico para la combinación izquierda o interna de una consulta previamente escrita. En este caso, supongamos que quiere ver como un conjunto de datos los registros no incluidos en la tabla a pero en la tabla b y en otra los registros no en la tabla b sino en la tabla a. Incluso entonces, solo tiendo a hacer esto para ahorrar tiempo investigando, pero lo cambiaría si fuera un código que se ejecutaría más de una vez.

Answer 7

Las sentencias SQL, además de ser correctas, deben ser tan fáciles de leer y expresivamente concisas como sea posible (porque representan acciones atómicas únicas, y su mente necesita asimilarlas por completo para evitar consecuencias involuntarias). A veces, una expresión se expresa más claramente con una combinación externa derecha.

Pero uno siempre puede transformarse en el otro, y el optimizador funcionará tan bien con uno como el otro.

Durante bastante tiempo, al menos uno de los principales productos rdbms solo admitía LEFT OUTER JOIN. (Creo que era MySQL)

Answer 8

Realmente no he tenido que pensar mucho sobre la combinación correcta, pero supongo que no he estado en casi 20 años escribiendo consultas SQL, he encontrado una justificación sólida para usar una. Ciertamente, he visto muchos de ellos, supongo, que surgen de los desarrolladores que han utilizado constructores de consultas integrados.

Siempre que he encontrado uno, he reescrito la consulta para eliminarlo. He descubierto que solo requieren demasiada energía mental adicional para aprender o volver a aprender si no has visitado la consulta durante un tiempo y no ha sido así. No ha sido común que la intención de la consulta se pierda o arroje resultados incorrectos, y generalmente es esta incorrección la que me ha llevado a solicitar que revise por qué las consultas no funcionaban.

Al pensarlo, una vez que introduces una combinación correcta, ahora tienes lo que consideraría ramas competidoras de la lógica que necesitan encontrarse en el medio. Si se introducen requisitos / condiciones adicionales, ambas ramas se pueden extender aún más y ahora tiene más complejidad que tiene que hacer malabares para asegurarse de que una rama no da lugar a resultados incorrectos.

Además, una vez que introduces una combinación correcta, otros desarrolladores menos experimentados que trabajan en la consulta más adelante simplemente pueden agregar tablas adicionales a la parte de la combinación correcta de la consulta y, al hacerlo, expandir los flujos lógicos de la competencia que aún deben reunirse en la mitad; o en algunos casos que he visto, comienzan a anidar vistas porque no quieren tocar la lógica original, tal vez en parte, esto se debe a que es posible que no comprendan la consulta o las reglas comerciales vigentes que impulsaron la lógica.

Answer 9

Nunca antes había utilizado right join y nunca pensé que realmente podría necesitarla, y parece un poco antinatural. Pero después de que lo pensé, podría ser realmente útil en la situación, cuando necesitas juntar una tabla con la intersección de muchas tablas, por lo que tienes tablas como esta:

Y quiero obtener un resultado como este:

O bien, en 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

Entonces, si cambias a la left join la left join , los resultados no serán los mismos.

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

La única forma de hacer esto sin la combinación correcta es usar expresión de tabla común o subconsulta

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 10

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

Reemplace [EN BLANCO] con:

IZQUIERDA: si desea todos los registros de la tabla 1, incluso si no tienen una columna que coincida con la de la tabla 2 (también se incluyen los registros de la tabla 2 con coincidencias)

DERECHA: si desea todos los registros de la tabla 2, incluso si no tienen una columna que coincida con la de la tabla 1 (también se incluyen registros de la tabla 1 con coincidencias)

COMPLETO: si desea todos los registros de la tabla 1 y de la tabla 2

¿De qué están hablando todos? Son lo mismo? No lo creo.

Answer 11

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

¿De qué otra forma podría unirse rápida / fácilmente a las primeras 2 tablas y unirse a table_c mientras se asegura que todas las filas en table_c siempre estén seleccionadas?