INNER JOIN EN vs de la cláusula where

StackOverflow https://stackoverflow.com/questions/1018822

  •  06-07-2019
  •  | 
  •  

Pregunta

Por simplicidad, suponga que todos los campos relevantes son NOT NULL.

Usted puede hacer:

SELECT
    table1.this, table2.that, table2.somethingelse
FROM
    table1, table2
WHERE
    table1.foreignkey = table2.primarykey
    AND (some other conditions)

O bien:

SELECT
    table1.this, table2.that, table2.somethingelse
FROM
    table1 INNER JOIN table2
    ON table1.foreignkey = table2.primarykey
WHERE
    (some other conditions)

Hacer estas dos trabajan en la misma forma en MySQL?

¿Fue útil?

Solución

INNER JOIN es la sintaxis ANSI que debe usar.

Generalmente se considera más legible, especialmente cuando se unen muchas tablas.

También se puede reemplazar fácilmente con un OUTER JOIN cuando surja una necesidad.

La sintaxis WHERE está más orientada al modelo relacional.

Un resultado de dos tablas JOIN ed es un producto cartesiano de las tablas a las que se aplica un filtro que selecciona solo aquellas filas con columnas de unión coincidentes.

Es más fácil ver esto con la sintaxis STRAIGHT_JOIN.

En cuanto a su ejemplo, en MySQL (y en SQL en general) estas dos consultas son sinónimos.

También tenga en cuenta que MySQL también tiene una cláusula <=>.

Usando esta cláusula, puede controlar el orden <=>: qué tabla se escanea en el bucle externo y cuál está en el bucle interno.

No puede controlar esto en MySQL usando la sintaxis <=>.

Otros consejos

Otros han señalado que INNER JOIN ayuda a la legibilidad humana, y esa es una prioridad principal; Estoy de acuerdo. Permítanme tratar de explicar por qué la sintaxis de combinación es más legible.

Una consulta básica SELECT es esta: 

SELECT stuff
FROM tables
WHERE conditions

La cláusula SELECT nos dice qué estamos recuperando; la cláusula FROM nos dice de dónde lo estamos obteniendo, y la cláusula WHERE nos dice cuáles estamos obteniendo.

JOIN es una declaración sobre las tablas, cómo se unen (conceptualmente, en realidad, en una sola tabla). Cualquier elemento de consulta que controle las tablas, de donde obtenemos cosas, pertenece semánticamente a la cláusula FROM (y, por supuesto, ahí es donde van los elementos JOIN). Poner elementos de unión en la cláusula WHERE combina el que y el de dónde ; por eso se prefiere la sintaxis JOIN.

Aplicación de sentencias condicionales en ON / WHERE

Aquí he explicado los pasos de procesamiento de consultas lógicas.

Referencia: Dentro de Microsoft & # 174; SQL Server & # 8482; Consulta T-SQL 2005
Editorial: Microsoft Press
Fecha de publicación: 07 de marzo de 2006
Imprimir ISBN-10: 0-7356-2313-9
Imprimir ISBN-13: 978-0-7356-2313-2
Páginas: 640

Inside Microsoft # 174; SQL Server & # 8482; Consulta T-SQL 2005 

(8)  SELECT (9) DISTINCT (11) TOP <top_specification> <select_list>
(1)  FROM <left_table>
(3)       <join_type> JOIN <right_table>
(2)       ON <join_condition>
(4)  WHERE <where_condition>
(5)  GROUP BY <group_by_list>
(6)  WITH {CUBE | ROLLUP}
(7)  HAVING <having_condition>
(10) ORDER BY <order_by_list>

El primer aspecto notable de SQL que es diferente de otros lenguajes de programación es el orden en que se procesa el código. En la mayoría de los lenguajes de programación, el código se procesa en el orden en que está escrito. En SQL, la primera cláusula que se procesa es la cláusula FROM, mientras que la cláusula SELECT, que aparece primero, se procesa casi en último lugar.

Cada paso genera una tabla virtual que se utiliza como entrada para el siguiente paso. Estas tablas virtuales no están disponibles para la persona que llama (aplicación cliente o consulta externa). Solo la tabla generada por el paso final se devuelve a la persona que llama. Si una determinada cláusula no se especifica en una consulta, simplemente se omite el paso correspondiente.

Breve descripción de las fases de procesamiento de consultas lógicas

No se preocupe demasiado si la descripción de los pasos no parece tener mucho sentido por ahora. Estos se proporcionan como referencia. Las secciones que vienen después del ejemplo de escenario cubrirán los pasos con mucho más detalle.

  1. FROM: se realiza un producto cartesiano (unión cruzada) entre las dos primeras tablas de la cláusula FROM y, como resultado, se genera la tabla virtual VT1.

  2. ON: el filtro ON se aplica a VT1. Solo las filas para las que <join_condition> es VERDADERO se insertan en VT2.

  3. OUTER (join): si se especifica un OUTER JOIN (en lugar de CROSS JOIN o INNER JOIN), las filas de la tabla o tablas preservadas para las que no se encontró una coincidencia se agregan a las filas de VT2 como filas externas, generando VT3. Si aparecen más de dos tablas en la cláusula FROM, los pasos 1 a 3 se aplican repetidamente entre el resultado de la última unión y la siguiente tabla en la cláusula FROM hasta que se procesen todas las tablas.

  4. WHERE: el filtro WHERE se aplica a VT3. Solo las filas para las que <where_condition> es VERDADERO se insertan en VT4.

  5. GROUP BY: las filas de VT4 se organizan en grupos según la lista de columnas especificada en la cláusula GROUP BY. Se genera VT5.

  6. CUBE | ROLLUP: los supergrupos (grupos de grupos) se agregan a las filas desde VT5, generando VT6.

  7. HAVING: el filtro HAVING se aplica a VT6. Solo los grupos para los que <having_condition> es VERDADERO se insertan en VT7.

  8. SELECT: se procesa la lista SELECT, generando VT8.

  9. DISTINCT: las filas duplicadas se eliminan de VT8. Se genera VT9.

  10. ORDER BY: las filas de VT9 se ordenan según la lista de columnas especificada en la cláusula ORDER BY. Se genera un cursor (VC10).

  11. ARRIBA: El número o porcentaje especificado de filas se selecciona desde el comienzo de VC10. La tabla VT11 se genera y se devuelve a la persona que llama.


     Por lo tanto, (INNER JOIN) ON filtrará los datos (el recuento de datos de VT se reducirá aquí mismo) antes de aplicar la cláusula WHERE. Las siguientes condiciones de unión se ejecutarán con datos filtrados que mejoran el rendimiento. Después de eso, solo la condición WHERE aplicará condiciones de filtro.

(La aplicación de declaraciones condicionales en ON / WHERE no hará mucha diferencia en algunos casos. Esto depende de cuántas tablas haya unido y el número de filas disponibles en cada tabla de unión)

La combinación implícita ANSI sintaxis es más, menos evidente y no se recomienda.

Además, el álgebra relacional permite la intercambiabilidad de los predicados en el WHERE la cláusula y la INNER JOIN, por lo que incluso INNER JOIN las consultas con WHERE las cláusulas pueden tener los predicados rearrranged por el optimizador.

Te recomiendo escribir las consultas en la mayoría de los readble manera posible.

A veces esto incluye la fabricación INNER JOIN relativamente "incompleta" y poner algunos de los criterios en la WHERE simplemente para hacer las listas de criterios de filtrado más fácilmente mantenible.

Por ejemplo, en lugar de:

SELECT *
FROM Customers c
INNER JOIN CustomerAccounts ca
    ON ca.CustomerID = c.CustomerID
    AND c.State = 'NY'
INNER JOIN Accounts a
    ON ca.AccountID = a.AccountID
    AND a.Status = 1

Escribir:

SELECT *
FROM Customers c
INNER JOIN CustomerAccounts ca
    ON ca.CustomerID = c.CustomerID
INNER JOIN Accounts a
    ON ca.AccountID = a.AccountID
WHERE c.State = 'NY'
    AND a.Status = 1

Pero depende, por supuesto.

Las uniones implícitas (que es lo que se conoce como su primera consulta) se vuelven mucho más confusas, difíciles de leer y difíciles de mantener una vez que necesita comenzar a agregar más tablas a su consulta. Imagínese haciendo esa misma consulta y tipo de unión en cuatro o cinco tablas diferentes ... es una pesadilla.

El uso de una unión explícita (su segundo ejemplo) es mucho más legible y fácil de mantener.

También señalaré que el uso de la sintaxis anterior está más sujeto a errores. Si utiliza uniones internas sin una cláusula ON, obtendrá un error de sintaxis. Si usa la sintaxis anterior y olvida una de las condiciones de unión en la cláusula where, obtendrá una unión cruzada. Los desarrolladores a menudo arreglan esto agregando la palabra clave distinta (en lugar de arreglar la unión porque todavía no se dan cuenta de que la unión en sí está rota), lo que puede parecer que soluciona el problema, pero ralentizará la consulta considerablemente.

Además, para el mantenimiento si tiene una unión cruzada en la sintaxis anterior, ¿cómo sabrá el mantenedor si quería tener una (hay situaciones en las que se necesitan uniones cruzadas) o si fue un accidente que debería arreglarse?

Permítame señalarle esta pregunta para ver por qué la sintaxis implícita es mala si usa combinaciones izquierdas. Sybase * = to Ansi Standard con 2 tablas externas diferentes para la misma tabla interna

Además (discurso personal aquí), el estándar que usa las uniones explícitas tiene más de 20 años, lo que significa que la sintaxis de unión implícita ha quedado desactualizada durante esos 20 años. ¿Escribiría el código de la aplicación utilizando una sintaxis que ha estado desactualizada durante 20 años? ¿Por qué quieres escribir el código de la base de datos que es?

Tienen un significado diferente legible para los humanos.

Sin embargo, dependiendo del optimizador de consultas, pueden tener el mismo significado para la máquina.

Siempre debe codificar para que sea legible.

Es decir, si esta es una relación incorporada, use la unión explícita. si coincide con datos débilmente relacionados, use la cláusula where.

El estándar SQL: 2003 cambió algunas reglas de precedencia, por lo que una declaración JOIN tiene prioridad sobre una " coma " unirse. En realidad, esto puede cambiar los resultados de su consulta dependiendo de cómo se configure. Esto causa algunos problemas para algunas personas cuando MySQL 5.0.12 cambió a adherirse al estándar.

Entonces, en su ejemplo, sus consultas funcionarían igual. Pero si agregaste una tercera tabla: SELECCIONAR ... DESDE tabla1, tabla2 UNIR tabla3 EN ... DONDE ...

Antes de MySQL 5.0.12, table1 y table2 se unirían primero, luego table3. Ahora (5.0.12 y en adelante), table2 y table3 se unen primero, luego table1. No siempre cambia los resultados, pero puede hacerlo y es posible que ni siquiera se dé cuenta.

Nunca uso la " coma " sintaxis más, optando por su segundo ejemplo. De todos modos, es mucho más legible, las condiciones de UNIÓN son con las UNIONES, no separadas en una sección de consulta separada.

Sé que estás hablando de MySQL, pero de todos modos: En Oracle 9, las uniones explícitas y las implícitas generarían diferentes planes de ejecución. AFAIK que se ha resuelto en Oracle 10+: ya no hay tanta diferencia.

La sintaxis de unión ANSI es definitivamente más portátil.

Estoy pasando por una actualización de Microsoft SQL Server, y también mencionaría que la sintaxis = * y * = para las uniones externas en SQL Server no es compatible (sin el modo de compatibilidad) para el servidor SQL 2005 y posterior.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top