SELECT * FROM TableA
INNER JOIN TableB
ON TableA.name = TableB.name
SELECT * FROM TableA, TableB
where TableA.name = TableB.name
¿Cuál es la forma preferida y por qué? ¿Habrá alguna diferencia de rendimiento cuando se utilicen palabras clave como JOIN?INNER JOIN palabras clave | con y sin usarlos
Gracias
La segunda forma es la forma clásica de hacerlo, desde antes de que existiera la palabra clave join.
Normalmente, el procesador de consultas genera las mismas operaciones de base de datos a partir de las dos consultas, por lo que no habría diferencia en el rendimiento.
El uso de join describe mejor lo que está haciendo en la consulta. Si tiene muchas combinaciones, también es mejor porque la tabla unida y su condición están una al lado de la otra, en lugar de poner todas las tablas en un lugar y todas las condiciones en otra.
Otro aspecto es que es más fácil hacer una unión ilimitada por error utilizando la segunda vía, lo que da como resultado una unión cruzada que contiene todas las combinaciones de las dos tablas.
averiguar mediante el uso de EXPLAIN SELECT …
que depende del motor utilizado, en el optimizador de consultas, en las teclas, en la mesa; en casi todo
Utilice la primera, ya que es:
En cuanto a rendimiento - no debería haber ninguna diferencia.
También le permite separar las condiciones de unión (en las cláusulas ON) de las condiciones del filtro (en la cláusula WHERE) –
La mayoría de las bases de datos actuales optimizarán ambas consultas en el mismo plan de ejecución. Sin embargo, use la primera sintaxis, es el estándar actual. Al aprender y utilizar esta sintaxis de unión, será útil cuando realice consultas con LEFT OUTER JOIN y RIGHT OUTER JOIN. que se vuelven difíciles y problemáticos usando la sintaxis anterior con las uniones en la cláusula WHERE.
He encontrado que en una base de datos correctamente normalizada, la unión DERECHA se debe utilizar raramente (¿alguna vez?), En una base de datos desnormalizada, sin embargo, esto no siempre es así. Utilizo esto como una medida de la necesidad de refactorizar la normalización/estructura. –
@Mark Schultheiss, vea esta pregunta: http://stackoverflow.com/questions/689963/does-anyone-use-right-outer-joins- –
exactamente, simplemente cambiando la secuencia de la tabla a menudo se hará una combinación de la derecha y la de la izquierda, que por mi experiencia es más fácil en ciclos de mantenimiento, especialmente para desarrolladores junior –
En algunos motores SQL, la segunda forma (uniones asociativas) está en desuso. Usa el primer formulario
En segundo lugar es menos explícito, hace que los iniciadores en SQL pausen al escribir el código. Es mucho más difícil de administrar en SQL complejo debido a la secuencia del requisito de coincidencia de unión para que coincida con la secuencia de la cláusula WHERE (coinciden en el código) o los resultados devueltos cambiarán haciendo que el conjunto de datos devuelto cambie, lo que realmente va en contra el pensamiento de que la secuencia no debería cambiar los resultados cuando se consideran los elementos en el mismo nivel.
Cuando se crean uniones que contienen varias tablas, se hace REALMENTE difícil codificar, bastante rápido usando el segundo formulario.
EDITAR: Rendimiento: Considero que la codificación, depuración facilita parte del rendimiento personal, por lo tanto, la facilidad de edición/depuración/mantenimiento es mejor con el primer formulario. Solo me lleva menos tiempo hacer cosas durante el desarrollo y ciclos de mantenimiento.
Para ser claros, la forma privada es '* =' y '= *' en el formulario para IZQUIERDA y DERECHA, no para la coma estándar ANSI para las tablas. ..sobre si agregué confusión por esa parte :) –
El filtrado se une únicamente al uso de DONDE puede ser extremadamente ineficiente en algunos escenarios comunes.Por ejemplo:
SELECT * FROM people p, companies c WHERE p.companyID = c.id AND p.firstName = 'Daniel'
La mayoría de las bases de datos se ejecute esta consulta, literalmente, tomando primero el producto cartesiano de las personas y empresas tablas y luego filtrado por los que tienen campos y CompanyID ID coincidente. Si bien el producto no restringido no existe en ningún lugar sino en la memoria y solo por un momento, su cálculo lleva algún tiempo.
Un mejor enfoque es agrupar las restricciones con las UNIONES cuando sea relevante. Esto no solo es subjetivamente más fácil de leer sino también mucho más eficiente. De esta manera:
SELECT * FROM people p JOIN companies c ON p.companyID = c.id
WHERE p.firstName = 'Daniel'
Es un poco más largo, pero la base de datos es capaz de mirar a la cláusula ON y utilizarla para calcular el totalmente restringido a unirse directamente, en lugar de comenzar con todo y luego limitar hacia abajo. Esto es más rápido de calcular (especialmente con grandes conjuntos de datos y/o combinaciones de varias tablas) y requiere menos memoria.
Cambio cada consulta que veo que usa la sintaxis "coma unir". En mi opinión, el único propósito de su existencia es la concisión. Teniendo en cuenta el impacto en el rendimiento, no creo que esta sea una razón convincente.
De acuerdo, el primero es mejor para la claridad y el control; es más fácil cambiar el tipo de unión si lo desea. –