Únase a la operación Vs Consulta anidada en DBMS

El crecimiento de la tecnología y la automatización junto con cantidades exponenciales de datos ha llevado a la importancia y omnipresencia de las bases de datos que, en pocas palabras, son colecciones organizadas de datos. Teniendo en cuenta un enfoque ingenuo, teóricamente se pueden mantener todos los datos en una tabla grande, sin embargo, eso aumenta el tiempo de acceso en la búsqueda de un registro, los problemas de seguridad si se destruye la tabla maestra, el almacenamiento redundante de información y otros problemas. Entonces, las tablas se descomponen en varias tablas más pequeñas. 

Para recuperar información de varias tablas, necesitamos extraer datos seleccionados de diferentes registros, utilizando operaciones llamadas unión (unión interna, unión externa y, lo que es más importante, unión natural). Considere 2 esquemas de tabla empleado (nombre_empleado, calle, ciudad) con n filas y trabajos (nombre_empleado, nombre_sucursal, salario) con m filas. Un producto cartesiano de estas 2 tablas crea una tabla con n*m filas. Una unión natural selecciona de estas n*m filas todas las filas con los mismos valores para employee_name. Para evitar la pérdida de información (algunas tuplas en empleado no tienen tuplas correspondientes en trabajos) usamos combinación externa izquierda o combinación externa derecha. 

Una combinación o una consulta anidada está mejor sujeta a condiciones: 
 

• Supongamos que nuestras 2 tablas están almacenadas en un sistema local. Realizar una combinación o una consulta anidada hará poca diferencia. Ahora permita que las tablas se almacenen en bases de datos distribuidas. Para una consulta anidada, solo extraemos la información relevante de cada tabla, ubicada en diferentes computadoras, luego fusionamos las tuplas obtenidas para obtener el resultado. Para una unión, se nos pedirá que obtengamos la tabla completa de cada sitio y creemos una tabla grande desde la cual se realizará el filtrado, por lo tanto, se requerirá más tiempo. Entonces, para bases de datos distribuidas, las consultas anidadas son mejores.
• El optimizador RDBMS se ocupa del rendimiento relacionado con la subconsulta o combinación escrita por el programador. Las uniones se entienden universalmente, por lo que no pueden surgir problemas de optimización. Si se requiere portabilidad a través de múltiples plataformas, evite las subconsultas, ya que pueden encontrarse con errores (el servidor SQL es más experto en uniones, ya que generalmente se usa con los editores de consultas gráficas de Microsoft que usan uniones).
• Específico de la implementación: supongamos que tenemos consultas en las que algunas de las consultas anidadas son constantes. En MySQL, cada subconsulta constante se evaluaría tantas veces como se encuentre, ya que no existe la función de caché. Este es un problema obvio si la subconsulta constante involucra tuplas grandes. Las subconsultas devuelven un conjunto de datos. Las uniones devuelven un conjunto de datos que necesariamente está indexado. Trabajar con datos indexados es más rápido, por lo que si el conjunto de datos devuelto por las subconsultas es grande, las uniones son una mejor idea.
• Las subconsultas pueden tardar más en ejecutarse que las uniones, dependiendo de cómo las trate el optimizador de la base de datos (pueden convertirse en uniones). Las subconsultas son más fáciles de leer, comprender y evaluar que las uniones crípticas. Permiten un enfoque de abajo hacia arriba, aislando y completando cada tarea secuencialmente.

Referir: operación de unión frente a consulta anidada