Unir consulta o subconsulta

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

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.

El primer principio es "Indique 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 layouts de consultas equivalentes deberían dar como resultado planes de consulta que sean los mismos (o al less igualmente eficientes).

Mi mayor frustración al usar MySQL por primera vez fue lo consciente que debía 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.

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

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

Si es posible, siempre intente hacer 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).

Teóricamente, cada subconsulta se puede cambiar a una consulta de combinación.

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 sets de resultados grandes nunca se utilizan subconsultas, en caso de que la subconsulta se ejecute para cada elemento del set de resultados.

cuidate, Alex

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

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

En SQL Server, una subconsulta correlacionada generalmente tiene un performance peor que una combinación o, a menudo incluso mejor para el performance, una unión a 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 de manera establecida