La mejor respuesta
Si bien tanto las uniones como las subconsultas tienen su lugar en las declaraciones SQL, yo personalmente siempre trato de escribir mis consultas utilizando combinaciones exclusivamente . Mientras tanto, solo presento una subconsulta cuando no puedo obtener los datos que quiero sin una.
La razón es que las uniones tienden a ejecutarse más rápido. De hecho, iría tan lejos como para decir que el tiempo de recuperación de la consulta usando combinaciones será casi siempre más rápido que el de una subconsulta.
La razón es que las combinaciones alivian la carga de cálculo en el base de datos reemplazando varias consultas con una consulta de combinación. Esto, a su vez, hace un mejor uso de las capacidades de la base de datos para buscar, filtrar y ordenar registros.
Por supuesto, a medida que agrega más combinaciones a una consulta, el servidor de la base de datos tiene que trabajar más, lo que traduce a tiempos de recuperación de datos más lentos.
Si bien las combinaciones son necesarias para recuperar datos de una base de datos normalizada, es importante que las combinaciones se escriban correctamente, ya que las combinaciones incorrectas pueden provocar una degradación grave del rendimiento y resultados de consulta inexactos.
En algunos casos, las subconsultas pueden reemplazar uniones y uniones complejas con solo un efecto negativo mínimo en el rendimiento.
Ejemplos de subconsultas
A veces no es posible utilizar una subconsulta. Aquí hay un par de ejemplos que utilizan la base de datos de muestra Sakila para MySQL y mi cliente de administración y desarrollo de base de datos Navicat .
Ejemplo # 1: Usar una función agregada como parte de una cláusula JOIN
La mayoría de las veces, las tablas se unen en un campo común. De hecho, no es inusual que el campo común también comparta el mismo nombre para mostrar que son los mismos datos. Sin embargo, en la siguiente consulta, la tabla de clientes se une a la última (MAX) create\_date para que los resultados de la consulta sean para el cliente que se registró más recientemente.
Se emplea una subconsulta porque no puede usar funciones agregadas como parte de una cláusula WHERE. ¡Esta ingeniosa solución elude esa limitación!
Ejemplo # 2:
En esta consulta, se emplea una subconsulta para obtener un conjunto de resultados intermedio para que podamos aplicar la función AVG () al COUNT de películas alquiladas. Esto es lo que llamo una agregación doble porque estamos aplicando una agregación (AVG) al resultado de otra (COUNT).
Esta consulta en particular es bastante rápida (solo toma 0.044 segundos) porque la consulta interna devuelve un solo valor. Por lo general, las consultas más lentas son aquellas que requieren escaneos completos de tablas.
Espero que responda a su pregunta.
¡Saludos!
Adam
Responder
Por lo general debe escribir consultas para que sean lo más claras posible y dejar la optimización al procesador de consultas del RDBMS y al DBA, si tiene uno, que es responsable de ajustar el diseño físico. debería resultar en un rendimiento suficientemente bueno en la mayoría de los casos, pero hay excepciones. A veces, el optimizador de consultas de un RDBMS tiene puntos ciegos o casos malos.
Ahora bien, si las uniones o las subconsultas van a ser un problema para un optimizador, es mucho más probable que esté en subconsultas. Eso es porque unirse es una característica básica del lenguaje que todos los usuarios, mientras que muchos usuarios no usan subconsultas en absoluto. Descubrí que convertir una aplicación de Sybase a SQL Server tuve que reescribir muchas subconsultas como uniones debido a errores en Microsoft «s manejo de subconsultas, aunque en un caso muy específico (donde la cláusula where de la subconsulta incluía un parámetro vinculado). No es sorprendente que SQL Server tuviera errores en las subconsultas porque muchos de sus clientes usan SQL Server con los editores de consultas gráficas de Microsoft, que naturalmente producen uniones pero no subconsultas.
Por lo general, desaconsejo la optimización prematura, pero haré una excepción aquí. Si su aplicación tiene que ser portátil a través de múltiples plataformas de base de datos, preferiría uniones a subconsultas en la mayoría de los casos porque es más probable que se encuentre con errores o malas elecciones de optimizador con subconsultas. Si su la aplicación no necesita ser portátil, escriba la consulta de la manera que parezca más natural y si no hay ningún problema, que será la mayor parte del tiempo, bien. Si hay un problema, vuelva a escribir la consulta de manera diferente para ver si eso ayuda. Y si tiene un DBA, consúltelo sobre cualquier problema de rendimiento que tenga.