Las consultas en lenguaje SQL no son fáciles de leer y menos si la consulta fue creada por otra persona; existen consultas muy complejas de entender y muy difíciles de modificar, leer una consulta simple es como seguir una historia, hay que leer desde el principio hasta el final; pero leer una consulta compleja (consulta anidada) es mucho más complicado, ya que se debe de leer desde la consulta más interna hasta la externa, esto sí y solo si la consulta anidada no está relacionada con otra consulta por medio de uniones (JOINS) ya que esto complica aún más para entender la consulta. Sin embargo, no solo basta con entender la consulta, hay que buscar la mejor manera de realizarla, para que el planificador de la misma, la resuelva usando los recursos de la mejor manera posible.
El planificador de la consulta, es una parte del manejador de base de datos, el cual busca el mejor camino para responder a lo que se pide en la consulta; el planificador después de haber encontrado el mejor camino, lo almacena en memoria y lo usa cuando se ejecute de nuevo la consulta. Esto no es tan fácil, si la consulta es modificada de manera incorrecta puede devolver el mismo contenido usando un plan diferente y consumiendo más recursos, a esto se le llama consulta “no entonada”.
Entonces, si la consulta es compleja, modificarla de manera óptima es un dolor de cabeza; para ello podemos usar una funcionalidad de PostgreSQL llamada CTE (Common Table Expressions) que no es más que una tabla temporal que solo existe en la transacción que se ejecuta …. diablos ya se complicó el tema…. bueno, en términos más manejables es una manera organizada y legible de realizar consultas complejas y que permite al planificador separar las rutas y buscar la más óptima. Veamos este ejemplo:
«select nombre,comp.cantidad_suma as cant_comp, fact.cantidad_suma as cant_fact From productos as prod, (select sum(cantidad) as cantidad_suma,producto from compras) as comp, (select sum(cantidad) as cantidad_suma,producto from facturas) as fact where prod.producto = comp.producto and fact.producto = prod.producto;»
Y ahora con CTE:
«with cp as (select sum(cantidad) as cant_sum,producto from compras ), ft as (select sum(cantidad) as cant_sum,producto from facturas), tot as (select cp.cant_sum as c_comp, ft.cant_sum as c_fact, ft.producto From cp,ft where cp.producto = ft.producto), select tot.c_comp, tot.c_fact, productos.nombre from productos,tot where tot.producto=productos.product;»
Estas consultas devuelven la misma cantidad de registros, la diferencia es que la que está hecha con CTE permite a una persona leerla más fácilmente, así como entenderla de una forma más simple y lo más importante, permite que el planificador genere un camino para cada una de las sub-consultas (cp, ft, tot) para luego usar esos caminos y emitir el resultado final haciendo uso de los recursos del equipo de manera óptima.
DesdeLaPlaza.com /Lennin Caro