Realmente depende, tuve situaciones en las que mejoré algunas consultas usando subconsultas.
Los factores que conozco son:
- si la subconsulta usa campos de consulta externa para comparar o no (correlacionado o no)
- si la relación entre la consulta externa y la consulta secundaria está cubierta por índices
- si no hay índices utilizables en las uniones y la subconsulta no está correlacionada y devuelve un resultado pequeño, podría ser más rápido usarlo
- También me he encontrado con situaciones en las que se transforma una consulta que usa order by en una consulta que no lo usa y luego se convierte en una simple subconsulta y ordenación que mejora el rendimiento en mysql
De todos modos, siempre es bueno probar diferentes variantes (con SQL_NO_CACHE, por favor), y convertir las consultas correlacionadas en uniones es una buena práctica.
Incluso iría tan lejos como para llamarlo una práctica muy útil.
Es posible que si las consultas correlacionadas son las primeras que le vienen a la mente, no está pensando principalmente en términos de operaciones de conjunto, sino principalmente en términos de operaciones de procedimiento y cuando se trata de bases de datos relacionales, es muy útil adoptar completamente el conjunto. perspectiva sobre el modelo de datos y transformaciones sobre el mismo.
EDITAR:Procedural vs Relacional
Pensar en términos de operaciones de conjuntos versus procedimientos se reduce a la equivalencia en algunas expresiones de álgebra de conjuntos, por ejemplo, la selección en una unión es equivalente a la unión de selecciones. No hay diferencia entre los dos.
Pero cuando compara los dos procedimientos, como aplicar los criterios de selección a cada elemento de una unión con hacer una unión y luego aplicar la selección, los dos son procedimientos claramente diferentes, lo que podría tienen propiedades muy diferentes (por ejemplo, utilización de CPU, E/S, memoria).
La idea detrás de las bases de datos relacionales es que no intente describir cómo obtener el resultado (procedimiento), sino solo lo que desea, y que el sistema de gestión de la base de datos decida cuál es el mejor camino (procedimiento) para cumplir con su solicitud. Esta es la razón por la que SQL se denomina lenguaje de cuarta generación (4GL) .
Uno de los trucos que le ayudarán a hacerlo es recordar que las tuplas no tienen un orden inherente (los elementos establecidos no están ordenados). Otro es darse cuenta de que el álgebra relacional es bastante completa y permite la traducción de solicitudes (requisitos) directamente a SQL (si la semántica de su modelo representa bien el espacio del problema, o en otras palabras, si el significado adjunto al nombre de sus tablas y relaciones está bien hecho, o en otras palabras, si su base de datos está bien diseñada).
Por lo tanto, no tienes que pensar cómo, solo qué.
En su caso, fue solo preferencia sobre consultas correlacionadas, por lo que puede ser que no le esté diciendo nada nuevo, pero enfatizó ese punto, de ahí el comentario.
Creo que si estuviera completamente cómodo con todas las reglas que transforman las consultas de un formulario a otro (reglas como distributividad) que no preferiría subconsultas correlacionadas (que vería todas las formas como iguales).
(Nota:lo anterior analiza los antecedentes teóricos, importantes para el diseño de la base de datos; prácticamente los conceptos anteriores se desvían:no todas las reescrituras equivalentes de una consulta se ejecutan necesariamente tan rápido, las claves primarias agrupadas hacen que las tablas hereden el orden en el disco, etc... pero estos las desviaciones son solo desviaciones; el hecho de que no todas las consultas equivalentes se ejecuten tan rápido es una imperfección del DBMS real y no de los conceptos detrás de él)
