¿Por qué utilizar JOIN en lugar de consultas internas

Question

me encuentro dispuesto a empujar a usar JOIN cuando puedo fácilmente resolver el mismo problema mediante el uso de una consulta interna:

por ejemplo,

SELECT COLUMN1, (SELECT COLUMN1 FROM TABLE2 WHERE TABLE2.ID = TABLE1.TABLE2ID) AS COLUMN2 FROM TABLE1;

Mi pregunta es, ¿es una mala práctica de programación? Me resulta más fácil de leer y mantener en comparación con una unión.

ACTUALIZACIÓN

quiero añadir que hay una gran respuesta aquí que en esencia está empujando a estar de nuevo a usar JOIN. Cada vez me encuentro menos involucrado en el uso de TSQL actualmente como resultado de las soluciones ORM (LINQ to SQL, NHibernate, etc.), pero cuando lo hago son cosas como subconsultas correlacionadas que me resultan más fáciles de escribir linealmente .

Answer 1

Personalmente, esto me parece increíblemente difícil de leer. No es la estructura que un desarrollador de SQL espera. Al usar JOIN, guarda todas las fuentes de la tabla en un solo lugar en lugar de distribuirlas a lo largo de su consulta.

¿Qué sucede si necesita tener tres o cuatro uniones? Poner todos esos en la cláusula SELECT se pondrá peludo.

Answer 2

Una unión suele ser más rápida que una subconsulta correlacionada, ya que actúa sobre el conjunto de filas en lugar de una fila a la vez. Nunca dejaré que este código vaya a mi servidor de producción.

Y encuentro una unión mucho más fácil de leer y mantener.

Answer 3

Si necesita más de una columna de la segunda tabla, necesitará dos subconsultas. Esto normalmente no funcionaría tan bien como una unión.

Answer 4

Esto no es una mala práctica de programación en absoluto IMO, aunque es un poco feo. En realidad, puede ser un aumento de rendimiento en situaciones donde la selección secundaria es de una tabla muy grande mientras espera un conjunto de resultados muy pequeño (debe considerar los índices y la plataforma, 2000 tiene un optimizador diferente y todo desde 2005). Aquí es cómo lo formato para que sea más fácil de leer.

select 
    column1 
    [column2] = (subselect...) 
from 
    table1 

Editar: Por supuesto, esto supone que su subselección sólo devolverá un valor, si no se le podría estar regresando malos resultados. Ver la respuesta de gbn.

Answer 5

que hace que sea mucho más fácil de usar otros tipos de uniones (externa izquierda, cruz, etc), ya que la sintaxis para aquellos en términos subconsulta es menos que ideal para facilitar la lectura

Answer 6

Esto no es equivalente a JOIN.

Si tiene varias filas en la TABLA2 para cada fila en TABLA1, no las obtendrá. Para cada fila en la TABLA1, se obtiene una fila de salida, por lo que no puede obtener múltiples de TABLE2.

Esto es por lo que haría uso de "Join": para asegurarse de que obtener los datos que quería ...

Después de su cambio: rara vez usar correlación con excepción existe ...

Answer 7

La consulta se utiliza se utiliza a menudo como un reemplazo de un LEFT JOIN para los motores que carecían de ella (más notablemente, PostgreSQL antes 7.2)

Este enfoque tiene algunos inconvenientes graves:

1. Se puede fallar si TABLE2.ID no es UNIQUE

2. Algunos motores no podrán usar nada más que NESTED LOOPS para esto q uery

3. Si es necesario seleccionar más de una columna, usted tendrá que escribir la subconsulta varias veces

Si el motor es compatible con LEFT JOIN, utilice el LEFT JOIN.

En MySQL, sin embargo, hay algunos casos en que una función de agregado en una subconsulta de nivel de selección puede ser más eficiente que en un LEFT JOIN con un .

Lee este artículo en mi blog para los ejemplos:

• Aggregates: subqueries vs. GROUP BY

Answer 8

Al final del día, el objetivo al escribir código, más allá de los requisitos funcionales, es hacer que la intención de tu código es claro para un lector Si usa un JOIN, la intención es obvia. Si utiliza una subconsulta de la manera que describe, se plantea la pregunta de por qué lo hizo de esa manera. ¿Qué intentabas lograr que un JOIN no hubiera logrado? En resumen, usted pierde el tiempo del lector al tratar de determinar si el autor estaba resolviendo algún problema de una manera ingeniosa o si estaban escribiendo el código después de una noche difícil de beber.