Esta lección no enseña sintaxis nueva. Enseña a decidir. Después de cuatro lecciones tienes dos cajas de herramientas que se solapan: casi todas las preguntas que sabes responder con un JOIN admiten también una subconsulta, y al revés. Y el problema de tener dos formas de escribir lo mismo es que nadie te dice cuál usar.

Hay una regla base que resuelve el 80 % de los casos en cinco segundos, cuatro grandes equivalencias que conviene conocer con sus dos escrituras, una diferencia real —no de estilo— entre IN y un INNER JOIN, y un criterio de rendimiento que hay que manejar con humildad: el optimizador reescribe muchas de estas consultas, y suponer cuál es más rápida sin medir es la forma más común de perder el tiempo.

1. La regla base
2. Equivalencia 1: IN frente a INNER JOIN (y la diferencia real)
3. Equivalencia 2: las cuatro formas de responder "qué no casa"
4. Equivalencia 3: escalar en el SELECT frente a LEFT JOIN + GROUP BY
5. Equivalencia 4: correlacionada frente a tabla derivada
6. Qué hace el optimizador por debajo
7. Legibilidad y mantenimiento, criterio de primera clase
8. Tabla-guía: quiero X → escribe Y
9. Errores Comunes y Consejos
10. Ejercicios
11. Conclusión del módulo

Si necesitas columnas de la otra tabla en el resultado, es un JOIN. Si solo necesitas filtrar o calcular un valor, suele ser una subconsulta.

Es sorprendentemente fiable. Léela como una pregunta sobre el SELECT, no sobre el WHERE: mira qué columnas quieres mostrar y de dónde salen.

Y su corolario, que es igual de útil: si te descubres escribiendo un JOIN seguido de un DISTINCT, casi siempre querías un EXISTS. El DISTINCT es el síntoma de que has traído filas que no necesitabas para responder a una pregunta de sí o no.

La pregunta: clientes que han hecho algún pedido.

Parecen la misma consulta. No lo son. La versión A devuelve una fila por cliente:

(4 primeras de 12 filas.)

La versión B devuelve las 20 filas de pedidos con los datos del cliente repetidos:

(6 primeras de 20 filas.) Esta es la diferencia de fondo entre las dos herramientas, y no es cuestión de gusto:

• IN es una prueba de pertenencia: pregunta "¿este valor está en la lista?" y responde una vez por fila externa. No puede multiplicar.
• JOIN es un producto filtrado: genera una fila por cada pareja que casa. Si la tabla derecha tiene tres coincidencias, salen tres filas.

Para igualarlas hay que añadir SELECT DISTINCT a la versión B — y ahí es donde el DISTINCT delata el problema. Además, DISTINCT obliga a ordenar o a construir una tabla hash sobre las 20 filas ya generadas: has hecho trabajo de más para luego deshacerlo.

El caso en que el JOIN sí es la respuesta correcta: si quisieras "clientes con la fecha de cada pedido", las 20 filas son el resultado que buscas, porque fecha_pedido es una columna de la otra tabla. La regla base en acción.

Aquí se cierra definitivamente el hilo abierto en 03-07 y desarrollado en 07-03. La pregunta —clientes que no han comprado nunca— tiene cuatro escrituras, todas correctas, todas identificando a los mismos tres clientes (Núria, Hugo e Inés):

La recomendación, en una línea: NOT EXISTS por defecto; anti-join si ya estabas uniendo esas tablas por otro motivo; EXCEPT para comparar conjuntos; NOT IN, nunca por costumbre.

La razón de descartar NOT IN como opción por defecto no es que sea peor hoy: es que su corrección depende de una propiedad del esquema —que la columna sea NOT NULL— que puede cambiar sin que nadie revise tus consultas. Una migración que permita nulos en empleado_id no dará ningún error y tus informes empezarán a devolver cero filas.

Ya viste las dos escrituras en 07-04. Aquí interesa el criterio:

El caso de una sola métrica, enfrentado:

(4 filas de las 15; idénticas en las dos versiones, incluidos los ceros de los clientes 13, 14 y 15.) Con una métrica la versión A gana en claridad: no toca el FROM, no necesita GROUP BY y no puede inflar nada. Y dos matices que suelen decidir la elección cuando hay más:

• La subconsulta es inmune a la multiplicación de filas. El LEFT JOIN con lineas_pedido obliga a COUNT(DISTINCT pe.id) para no contar 9 pedidos donde hay 3.
• El GROUP BY es inmune a la repetición. Añadir una métrica nueva es una línea; con subconsultas es copiar un bloque de cuatro líneas y cambiar el agregado.

Hay un tercer caso donde la subconsulta gana claramente: cuando la métrica no se puede expresar con un agregado sobre el JOIN. "El importe del último pedido de cada cliente" no es ningún SUM ni MAX de las columnas unidas: exige ordenar y cortar. Ahí toca subconsulta correlacionada, LATERAL (07-04) o función de ventana (10-03).

La pregunta: productos por encima de la media de su categoría (las 8 filas de 07-02).

Las mismas 8 filas, y la versión B además muestra el umbral:

(4 primeras de 8 filas; cierran los productos 10, 13, 15 y 19.) Las diferencias:

Con pocas filas y una sola comparación, la correlacionada es más legible. En cuanto quieras mostrar el valor de referencia, reutilizarlo o aplicarlo sobre millones de filas, la tabla derivada es mejor — y con tres pasos, la CTE de 10-02 es mejor que las dos.

Antes de decidir por rendimiento, conviene saber que el motor no ejecuta lo que escribes, sino un plan equivalente que él elige. PostgreSQL aplica varias transformaciones automáticas:

De aquí salen las tres conclusiones prácticas del módulo:

1. IN y EXISTS frente a un JOIN son, en rendimiento, prácticamente lo mismo en PostgreSQL moderno. Elige por legibilidad, no por velocidad.
2. NOT IN sí es más lento, además de peligroso, porque el optimizador tiene las manos atadas por la semántica de los nulos.
3. Las correlacionadas en el SELECT son la construcción con más riesgo real: son las que más a menudo se ejecutan literalmente, una vez por fila.

No optimices a ciegas. "Las subconsultas son lentas" es un mito que circula desde MySQL 5.5, donde efectivamente lo eran. Con PostgreSQL 16 casi nunca es cierto, y con otros motores depende de la versión. La única forma honesta de saberlo es medir: EXPLAIN ANALYZE te enseña el plan real y los tiempos, y es la lección 08-05. Hasta entonces, escribe la versión más legible.

Cuando dos escrituras tienen el mismo rendimiento —que es lo habitual—, la legibilidad no es un criterio secundario: es el criterio. Una consulta se escribe una vez y se lee, se depura y se modifica decenas de veces.

Compara. La versión anidada de "clientes cuyo ticket medio supera la media global", con tres niveles:

Se lee de dentro hacia fuera, la sangría consume media pantalla y el cálculo del total de pedido está escrito dos veces. La misma lógica con CTE:

Cada paso tiene nombre, se lee de arriba abajo como un procedimiento, y totales_pedido se define una vez y se usa dos. Eso es 10-02, y es la razón por la que este módulo insiste en remitir allí: las subconsultas resuelven el problema, las CTE lo dejan legible.

Tres señales de que una consulta pide reescritura:

• Más de dos niveles de anidamiento. Cuenta paréntesis de apertura seguidos.
• La misma expresión escrita dos o más veces. Un SUM(...) repetido en el SELECT y en el HAVING es deuda técnica.
• Tres o más subconsultas casi idénticas en el SELECT. Es un GROUP BY esperando a nacer.

• Usar JOIN para una pregunta de existencia. Multiplica filas y te obliga a un DISTINCT que oculta el problema: 20 filas donde querías 12.
• Creer que "las subconsultas son lentas". En PostgreSQL 16, IN y EXISTS se convierten en semi-joins. El mito viene de motores y versiones antiguos.
• Reescribir por rendimiento sin medir. Cambiar una consulta legible por una críptica basándote en una intuición es la peor operación posible: pierdes legibilidad y puede que no ganes nada (08-05).
• Mantener NOT IN porque "hoy funciona". Su corrección depende de una propiedad del esquema que puede cambiar sin avisar.
• Anidar tres niveles cuando existe una CTE. Funciona, pero nadie —tú incluido— podrá modificarla dentro de seis meses.
• Repetir la misma expresión en SELECT, WHERE y HAVING. Cada copia es una oportunidad de que una se actualice y las otras no.
• Consejo: escribe primero la versión que se parezca a la pregunta. Si la pregunta dice "clientes que no han comprado", escribe NOT EXISTS. La consulta que se lee como el enunciado es la que menos errores esconde.
• Consejo: cuenta las filas de cada versión antes de dar una por buena. Si dos escrituras "equivalentes" devuelven 12 y 20 filas, no eran equivalentes.
• Consejo: guarda las dos versiones cuando dudes. Deja la alternativa comentada con una nota de por qué elegiste la otra. Es la documentación más barata que existe.

Para cada una de estas cinco preguntas, decide JOIN o subconsulta aplicando la regla base, y justifica en una frase. No hace falta escribir el SQL completo.

1. Productos con su categoría y su proveedor.
2. Productos que han recibido alguna reseña.
3. Pedidos cuyo importe supera el ticket medio global.
4. Clientes con el número de pedidos que han hecho.
5. Empleados que nunca han gestionado un pedido.

Un compañero ha escrito esto para "los productos que se han vendido alguna vez":

1. ¿El resultado es correcto? ¿Cuántas filas devuelve antes y después del DISTINCT?
2. Reescríbela con EXISTS y explica qué se gana.
3. ¿En qué caso el JOIN sería la escritura correcta para una pregunta parecida?

Toma esta consulta, que responde a "clientes con más de un pedido y su facturación total":

1. ¿Cuántas ejecuciones de subconsulta implica?
2. Reescríbela con JOIN y GROUP BY, cuidando el recuento.
3. Da el resultado y di qué versión defenderías en una revisión de código.

Solución 1

Solución 2

1. El resultado es correcto, pero por accidente del DISTINCT. Sin él, el JOIN devuelve 47 filas —una por línea de pedido—, con el aceite de oliva repetido 5 veces y el arroz 4. Con DISTINCT quedan 17 filas, los 17 productos vendidos. Es decir: el motor genera 47 filas, las ordena o las mete en una tabla hash, y descarta 30. Trabajo hecho para deshacerlo.

2. Con EXISTS:

17 filas directamente, sin generar las 47 ni deduplicar. Se gana: el resultado no puede duplicarse por construcción, la intención queda explícita ("productos que tienen alguna venta"), el EXISTS cortocircuita en la primera línea encontrada, y el DISTINCT desaparece —con él, el riesgo de que alguien añada mañana una columna de lineas_pedido al SELECT y el DISTINCT deje de deduplicar sin que nadie lo note.

3. El JOIN sería correcto en cuanto la pregunta pidiera algo de lineas_pedido: "productos vendidos con las unidades de cada venta" (47 filas, y son el resultado), o "productos vendidos con el total de unidades" (17 filas, con GROUP BY). En cuanto necesites datos de la otra tabla, la regla base manda.

Solución 3

1. Las ejecuciones. Tres subconsultas por cliente —dos en el SELECT y una repetida en el WHERE— × 15 clientes = 45, de las cuales 15 son un COUNT calculado dos veces por cliente. Ese COUNT duplicado es el síntoma clásico: el WHERE no ve los alias del SELECT (orden lógico del módulo 2), así que hay que repetir la expresión entera.

2. La reescritura:

7 clientes, los mismos que salían en 04-06 con HAVING COUNT(*) > 1. Dos detalles obligatorios: COUNT(DISTINCT pe.id), porque el segundo JOIN multiplica cada pedido por sus líneas (Lucía tendría 9 pedidos en vez de 3); y INNER JOIN en lugar de LEFT, que aquí es correcto porque la condición > 1 ya excluye a quien tiene 0.

3. Cuál defender. La versión con GROUP BY, sin dudarlo: una pasada en lugar de 45, la expresión del importe escrita una sola vez y el criterio de corte visible en el HAVING junto a la columna que muestra. La versión con subconsultas tiene una única ventaja real —no necesita COUNT(DISTINCT), porque no multiplica filas— y esa ventaja no compensa repetir el COUNT en dos sitios. Si la consulta creciera a cinco métricas, la diferencia dejaría de ser discutible.

(Y la versión ideal, con el total de pedido calculado una sola vez y nombrado, llega en 10-02.)

Cierras el módulo 7 con un criterio, no solo con sintaxis:

• La regla base: si necesitas columnas de la otra tabla, JOIN; si solo filtras o calculas un valor, subconsulta. Y si escribes JOIN ... DISTINCT, querías EXISTS.
• IN frente a INNER JOIN no es una cuestión de estilo: son 12 filas frente a 20. IN prueba pertenencia y responde una vez por fila; el JOIN produce una fila por pareja.
• Las cuatro formas de responder "qué no casa" quedan zanjadas: NOT EXISTS por defecto, anti-join si ya unías esas tablas, EXCEPT para comparar conjuntos, y NOT IN nunca por costumbre — porque su corrección depende de una propiedad del esquema que puede cambiar sin avisar.
• Una métrica por fila cabe bien en una escalar del SELECT; tres o más piden LEFT JOIN + GROUP BY, cuidando el COUNT(DISTINCT).
• Correlacionada o tabla derivada: la primera se lee como la pregunta, la segunda calcula seis medias en vez de veinte y te regala la columna de referencia.
• El optimizador reescribe IN, EXISTS y NOT EXISTS como semi-joins y anti-joins, así que su rendimiento suele ser equivalente al del JOIN; NOT IN y las correlacionadas en el SELECT son las que de verdad se pagan. Y nada de esto se supone: se mide con EXPLAIN ANALYZE (08-05).
• La legibilidad es un criterio de primera clase: tres niveles de anidamiento o una expresión repetida son señales de que toca una CTE (10-02).

Y con esto se cierra el módulo 7. Repasa lo que has ganado en cinco lecciones: distingues una subconsulta no correlacionada de una correlacionada y sabes que la segunda se evalúa una vez por fila; reconoces las escalares, las de fila y las de tabla, y los operadores que admite cada una; has resuelto por fin la pregunta que 04-06 dejó pendiente —Julien, Sofia y Tiago superan el ticket medio de 36,40 €—; dominas EXISTS y NOT EXISTS, incluida la doble negación de la división relacional; colocas subconsultas en el SELECT, en el FROM, en el WHERE, en el HAVING y en las instrucciones del módulo 5; y con las tablas derivadas has liquidado por fin el problema de los portes que arrastrabas desde el módulo 3: 727,95 € + 118,25 € = 846,20 €, cuadrado al céntimo.

Con los siete módulos que llevas, puedes escribir casi cualquier consulta que TiendaVerde necesite. Y justo por eso, la pregunta importante cambia. Hasta ahora ha sido siempre la misma: ¿esto devuelve lo que quiero?. A partir de aquí es otra: ¿cuánto tarda?. Con 20 pedidos, 47 líneas y 15 clientes, todo lo que has escrito responde en milisegundos, y da exactamente igual que una subconsulta se ejecute veinte veces o una sola. Con 20 millones de pedidos, esa misma consulta puede tardar minutos, bloquear una pantalla de administración o tumbar un informe nocturno. En el módulo 8, Índices y rendimiento, aprenderás qué es un índice y cómo convierte un recorrido completo de la tabla en una búsqueda dirigida, cómo crearlos y gestionarlos, qué tipos existen y —tan importante como lo anterior— cuándo no indexar, las técnicas de optimización de consultas, y EXPLAIN, la herramienta que te dirá por fin, con datos y no con intuiciones, qué está haciendo realmente el motor con el SQL que escribes.