Realmente depende, tuve situaciones en las que he mejorado algunas consultas mediante el uso de subconsultas.
Los factores que soy consciente son:
- si la subconsulta utiliza campos de consulta externa para la comparación o no (correlated o no)
- si la relación entre la consulta externa y consulta sub está cubierto por índices
- si no hay índices utilizables en las uniones y la subconsulta no está correlacionada y devuelve un pequeño resultado podría ser más rápido usarlo
- También he encontrado situaciones en las que se transforma una consulta que utiliza el orden por aq uery que no utiliza y que convertirlo en un simple sub consulta y la clase que mejora el rendimiento de MySQL
De todos modos, siempre es bueno probar diferentes variantes (con SQL_NO_CACHE por favor), y girando consultas correlacionadas en las combinaciones esté una buena práctica.
Incluso llegaría a decir que es una práctica muy útil.
Es posible que si las consultas correlacionadas son las primeras que le vienen a la mente que 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 la perspectiva establecida sobre el modelo de datos y las transformaciones en él.
EDIT: Procesal vs relacional
Pensando en términos de operaciones de conjuntos vs procedimiento se reduce a la equivalencia en algunas expresiones de álgebra conjunto, por ejemplo, la selección de una unión es equivalente a la unión de las selecciones. No hay diferencia entre los dos.
Pero cuando se comparan los dos procedimientos, tales como aplicar los criterios de selección para todos los elementos de una unión con hacer una unión y luego aplicar la selección, los dos son muy diferentes procedimientos, lo que podría tener propiedades muy diferentes (por ejemplo, la utilización de la CPU , E/S, memoria).
La idea detrás de las bases de datos relacionales es que no intentas describir cómo obtener el resultado (procedimiento), sino solo lo que deseas, y que el sistema de gestión de base de datos decidirá la mejor ruta para completar tu solicitud. Es por eso que SQL se llama 4th generation language (4GL).
Uno de los trucos que ayudan a hacer que es recordar que las tuplas no tienen un orden inherente (conjunto de elementos no tienen orden). Otra es darse cuenta de que el álgebra relacional es bastante amplio y permite la traducción de las solicitudes (requisitos) directamente a SQL (si la semántica de su modelo representan así el espacio del problema, o en otras palabras, si el significado vinculado al nombre de las tablas y las relaciones que se hace correcto, o en otras palabras si su base de datos está bien diseñada).
Por lo tanto, usted no tiene que pensar cómo, sólo lo.
En su caso, era solo preferencia sobre las consultas correlacionadas, por lo que podría ser que no le dijera nada nuevo, pero hizo hincapié en ese punto, de ahí el comentario.
Creo que si estuvieras completamente cómodo con todas las reglas que transforman consultas de una forma a otra (rules como distributiveness) no querrías subconsultas correlacionadas (que verías todas las formas como iguales).
(Nota: anteriormente se discuten los antecedentes teóricos, importantes para el diseño de bases de datos; prácticamente todos los conceptos anteriores se desvían; no todas las reescrituras equivalentes de una consulta se ejecutan necesariamente como claves primarias rápidas, agrupadas hacen que las tablas hereden orden en el disco, etc. .. pero estas 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)
También me gustaría saber sobre esto. – IsmailS
Dudo que importe en absoluto el rendimiento, al menos en MS SQL Server. MySQL no es tan inteligente ... – Thorarin