Únase a la consulta o subconsulta

Question

¿Existen reglas básicas para que los desarrolladores utilicen join en lugar de subconsulta o son lo mismo?

Answer 1

Depende de RDBMS. Debe comparar los planes de ejecución para ambas consultas.

En mi experiencia con Oracle 10 y 11, los planes de ejecución son siempre los mismos.

Answer 2

Teóricamente cada subconsulta puede cambiarse a una consulta de unión.

Answer 3

En cuanto a rendimiento, no tienen ninguna diferencia en la mayoría de los motores DB modernos.

Answer 4

El problema con las subconsultas es que puede terminar teniendo un sub-conjunto de resultados sin ninguna clave, por lo que unirlas sería más costoso.

Si es posible, siempre intente realizar consultas JOIN y filtrar con la cláusula ON, en lugar de WHERE (aunque debería ser el mismo, ya que los motores modernos están optimizados para esto).

Answer 5

Como con muchas cosas, depende. - cuán compleja es la subconsulta - en una consulta con qué frecuencia se ejecuta la subconsulta

Intento evitar las subconsultas siempre que puedo. Especialmente cuando se esperan conjuntos de resultados grandes nunca se utilizan subconsultas, en caso de que la subconsulta se ejecute para cada elemento del conjunto de resultados.

cuidar, Alex

Answer 6

En SQL Server una consulta correlacionada normalmente realiza peor que una unión o, a menudo incluso mejor para un rendimiento, una combinación de una tabla derivada. Casi nunca escribo una subconsulta para nada que tenga que realizarse varias veces. Esto se debe a que las subconsultas correlacionadas a menudo básicamente convierten su consulta en un cursor y ejecutan una fila a la vez. En las bases de datos, generalmente es mejor hacer las cosas en forma de conjunto

Answer 7

Vamos a ignorar el impacto en el rendimiento por ahora (como deberíamos si somos conscientes de que "la optimización prematura es la raíz de todo mal").

elegir lo que se ve más claro y más fácil de mantener.

Answer 8

El primer principio es el "estado de la consulta con precisión". El segundo principio es "declarar la consulta simple y obviamente" (que es donde generalmente se toman decisiones). El tercero es "declarar la consulta, por lo que se procesará de manera eficiente".

Si se trata de un dbms con un buen procesador de consultas, los diseños de consultas equivalentes deberían dar como resultado planes de consulta que son iguales (o al menos igualmente eficientes).

Mi mayor frustración con el uso de MySQL por primera vez fue lo consciente que tenía que ser para anticipar el optimizador. Después de una larga experiencia con Oracle, SQL Server, Informix y otros productos dbms, rara vez esperaba preocuparme por esos problemas. Ahora es mejor con versiones más nuevas de MySQL, pero todavía es algo a lo que termino necesitando prestar atención más a menudo que con los demás.