Cuando una consulta SQL crece en complejidad, las subqueries anidadas se convierten en un problema real. Tres, cuatro o cinco niveles de profundidad hacen que nadie entienda el código al día siguiente. Existe una forma mucho más limpia y profesional de resolver esto: las CTE o Common Table Expressions, consultas nombradas que se leen como pasos de un proceso y que representan la manera en que los profesionales escriben consultas complejas en producción.
¿Por qué las subqueries anidadas se vuelven un problema?
El escenario planteado es claro: identificar los tres vendedores top por país, mostrando solo aquellos países donde el volumen total de ventas supera cierto umbral [01:10]. Para resolverlo con subqueries anidadas, se necesitan al menos tres niveles de lógica encapsulados uno dentro de otro:
- Una base que obtiene todos los empleados que vendieron por país y cuánto vendió cada uno.
- Sobre esa base, una subquery que calcula el ranking de cada vendedor dentro de su país.
- Una subquery externa que filtra por el umbral de ventas deseado y ordena los resultados.
El resultado funciona. Puedes cambiar el umbral a diez mil, veinte mil o veinticinco mil unidades y obtienes los vendedores correspondientes [03:05]. Pero el costo es alto: construir esa consulta requiere mucho tiempo, y si vuelves a verla seis meses después, vas a perder horas tratando de interpretar qué hace cada nivel de anidación.
¿Qué es la deuda técnica en SQL?
Cuando el código no se entiende, se convierte en deuda técnica [08:22]. Cada consulta confusa que queda en producción es tiempo futuro desperdiciado. Con tres lógicas anidadas ya resulta complejo; con cuatro, cinco o siete, la situación se vuelve inmanejable.
¿Cómo funcionan las CTEs o Common Table Expressions?
La estructura de una CTE comienza con la palabra clave WITH [05:12]. Lo que hace es tomar cada expresión, nombrarla con un alias usando AS, ejecutar la query correspondiente y guardarla como una tabla virtual en memoria. Luego, cada paso siguiente puede referenciar las tablas anteriores por su nombre.
Para el mismo problema de los vendedores top, la CTE se organiza en pasos claros:
- Paso uno: se crea una tabla llamada
ventas_por_empleado que calcula las ventas totales de cada empleado por sucursal [05:30].
- Paso dos: se crea
ConRanking, que toma los datos de ventas_por_empleado y asigna un ranking por país [05:55].
- Paso tres: se genera
paises_relevantes, que filtra los países cuyo volumen supera el umbral definido [06:20].
Finalmente, un SELECT simple une las tres tablas virtuales y entrega el resultado final. Al ejecutar ambas versiones, subquery anidada y CTE, el resultado es idéntico: los mismos siete vendedores top con los mismos datos [07:00].
¿Cuándo conviene usar CTEs en lugar de subqueries?
La diferencia está en la legibilidad. Entender el SELECT final de una CTE es mucho más simple que descifrar una subquery con tres niveles de profundidad. Las ventajas concretas son:
- Más legibles: cada paso tiene un nombre descriptivo que explica su propósito.
- Más eficientes: en algunos casos, el motor de base de datos optimiza mejor las CTEs [08:10].
- Más mantenibles: modificar un paso no requiere entender toda la cadena de anidación.
La recomendación es directa: usa CTEs cuando la consulta tenga más de dos o tres pasos lógicos claros [08:35]. Tu versión futura te lo agradecerá.
¿Qué viene después de dominar las CTEs?
Las vistas son esencialmente CTEs persistentes en la base de datos [08:50]. Cualquier persona puede utilizarlas sin saber SQL, lo que las convierte en una herramienta poderosa para equipos multidisciplinarios. Como desafío práctico, en los recursos de la clase hay una consulta con subqueries anidadas lista para ser reescrita con CTEs. Comparte tu versión en los comentarios y compara enfoques con otros estudiantes.
