Query SQL con UNION y con UNION ALL (y 2)

Hace unas semanas comenzamos a ver cómo debían implementarse las queries con las cláusulas UNION ALL y UNION. La ventaja de estos comandos es que nos permiten rebajar drásticamente los tiempos de ejecución de las sentencias SQL que tengamos insertadas en el código de nuestros objetos Cobol. Aunque en principo esto pueda parecer poco relevante, en cuanto vayamos teniendo más experiencia lo normal es que también vaya aumentando la preocupación por el rendimiento de nuestros programas.

En la primera parte del post nos centramos en analizar cómo debía codificarse una query con la cláusula UNION (ver post Query SQL con UNION y con UNION ALL - 1). Hoy, para completar la visión global, vamos a examinar cómo debería implementarse una query con UNION ALL. Y, lo que es más importante, explicaremos cuál es la diferencia entre la instrucción UNION ALL y la instrucción UNION del lenguaje SQL.

Diferencia entre UNION ALL y UNION

Más arriba he hablado de la cláusula UNION ALL y de la cláusula UNION. ¿Cuál es la diferencia entre ambas? En realidad, son dos variantes del mismo concepto. En general, nos será más útil el comando UNION, pero es posible que alguna vez nos venga bien utilizar UNION ALL.

La ejecución de la query con UNION nos va a extraer el listado de datos eliminando todos aquellos registros que estén duplicados. ¿Cuáles se consideran duplicados? Pues aquellos registros que tengan provisionados valores idénticos en todos aquellos campos especificados en la cláusula SELECT (si hemos puesto un * entonces serían todos los campos del registro).

Siguiendo con este razonamiento, la ejecución de la misma query con UNION ALL nos va a extraer el listado de datos incluyendo todos aquellos registros que estén duplicados. Por eso decía que, en general, preferiremos usar el comando UNION. Eso sí, alguna vez puede que necesitemos recuperar el listado completo (con todos sus duplicados) y para eso nos vendrá muy bien el comando UNION ALL.



En el ejemplo anterior, el uso de UNION ALL no cambiaría demasiado el aspecto del código SQL. Quedaría del siguiente modo.

  SELECT *                                                     
  FROM JJDB22.JJETRAT0 A, JJDB22.JJTRAMT0 B
  WHERE                                                        
     ( A.JJTU_CO_INTERN = 'Z.BR' AND A.JJCA_CO_INTERN = 1)

    AND A.JJTU_CO_INTERN   = B.JJTU_CO_INTERN                  
    AND A.JJCA_CO_INTERN   = B.JJCA_CO_INTERN                   
    AND A.JJAM_NU_INTERN   = B.JJAM_NU_INTERN  

  UNION ALL

  SELECT *                                                     
  FROM JJDB22.JJETRAT0 A, JJDB22.JJTRAMT0 B
  WHERE                                                        
     (A.JJTU_CO_INTERN_1 = 'Z.BR' AND A.JJCA_CO_INTERN_1 = 1)
                  
    AND A.JJTU_CO_INTERN_1 = B.JJTU_CO_INTERN_1  
    AND A.JJCA_CO_INTERN_1 = B.JJCA_CO_INTERN_1  
    AND A.JJAM_NU_INTERN   = B.JJAM_NU_INTERN

Como vemos, se trata prácticamente de la misma query. Simplemente tendremos que decidir previamente si necesitamos los registros duplicados o no.

Conclusiones acerca de UNION ALL y UNION

Tal y como hemos podido comprobar a lo largo del post, la cláusula UNION nos puede resultar muy útil en aquellos casos en los que tengamos que mejorar el rendimiento de una query compleja. Como he podido comprobar en numerosas ocasiones, su uso suele tener mucho éxito a la hora de bajar los tiempos de ejecución por debajo de los 100 milisegundos. Así que tenedlo en cuenta a la hora de implementar los objetos Cobol.

Normalmente, yo suelo utilizar UNION para problemas de rendimiento. Por contra, dejo UNION ALL para casuísticas muy especiales en las que necesito conocer el número de registros que hay en una determinada tabla DB2. Si puedo prescindir de dicho dato, entonces prefiero obtener los listados sin registros duplicados.

En los ejemplos habéis podido comprobar que la implementación de un UNION es muy sencilla. La verdadera dificultad viene a la hora de pensar cómo se puede dividir una query compleja en varias queries más sencillas. Es decir, se trata más de un problema funcional que de una dificultad técnica.



Pero no os preocupéis. Con un poco de experiencia se va haciendo cada vez más fácil la tarea de dividir queries. Como punto de partida, en estos casos en los que preciséis mejorar el rendimiento, podéis echarle un vistazo a las declaraciones en las que se estén empleando operadores OR. Normalmente, no es difícil fraccionar estas sentencias en varias queries más simples.

Pues nada, eso es todo por hoy. Espero que lo comentado a lo largo del artículo os sea útil para entender el funcionamiento de UNION ALL y de UNION. En caso de que os quede alguna duda, ya sabéis que aquí abajo tenéis el apartado de comentarios...

Saludos.