Cerraste el módulo 2 chocando siempre contra el mismo techo: pedidos te dice cliente_id = 9 y no "Camille Dubois", lineas_pedido te dice producto_id = 15 y no "Té verde matcha ceremonial". Ese techo se acaba aquí. En esta lección aprenderás qué es realmente un JOIN, no como una fórmula que se copia sino como una operación que puedes reconstruir mentalmente paso a paso: un producto cartesiano filtrado por una condición. A partir de esa idea, todo lo demás —INNER, LEFT, RIGHT, FULL, SELF, CROSS— deja de ser una lista de nombres que memorizar y se convierte en variaciones sobre un mismo mecanismo.

Esta es la lección paraguas del módulo: te da el marco conceptual, la sintaxis y la panorámica de los cinco tipos. Cada uno de ellos se desarrolla a fondo en las lecciones siguientes.

1. Por qué hay que recomponer lo que la normalización separó
2. Qué es un JOIN: producto cartesiano filtrado
3. La cláusula ON y la condición de emparejamiento
4. Sintaxis moderna frente a la antigua de comas
5. El CROSS JOIN accidental
6. USING y NATURAL JOIN
7. Alias de tabla y la ambigüedad de nombres
8. Panorámica de los cinco tipos de JOIN
9. Encadenar tres o más tablas
10. Los JOIN en el orden lógico de ejecución
11. Errores Comunes y Consejos
12. Ejercicios
13. Conclusión

En la lección 01-05 justificamos por qué el nombre de la categoría no se guarda dentro de cada producto: si "Cosmética natural" apareciera repetido en cuatro filas de productos, corregir una errata exigiría cuatro UPDATE, y bastaría con olvidar uno para tener dos versiones del mismo dato conviviendo en la tabla. La normalización resuelve eso guardando el nombre una sola vez, en categorias, y dejando en productos únicamente una referencia numérica: categoria_id.

El precio de esa decisión es exactamente el techo del módulo 2:

Un 1 no le sirve a nadie en un informe. El dato existe, pero está repartido entre dos tablas, y hace falta una operación que las vuelva a juntar en el momento de consultar.

La idea clave del módulo: normalizar es separar para almacenar bien; el JOIN es volver a juntar para consultar bien. Son las dos caras de la misma moneda, y por eso una base de datos bien diseñada no es una base de datos incómoda: solo exige aprender a recorrer las relaciones.

La definición formal de un JOIN cabe en una frase:

Un JOIN es el producto cartesiano de dos tablas, filtrado por una condición.

El producto cartesiano empareja cada fila de la primera tabla con cada fila de la segunda. Si la primera tiene 3 filas y la segunda 2, el resultado tiene 3 × 2 = 6.

Vamos a verlo con dos extractos diminutos de TiendaVerde antes de tocar las tablas completas. Estas son las dos "tablas" de trabajo:

Extracto de categorias (2 filas):

Extracto de productos (3 filas):

6 filas. Todas las combinaciones posibles. La mayoría son basura: la Kombucha no pertenece a "Higiene personal" y el cepillo de dientes no es una bebida.

Las filas buenas son aquellas en las que p.categoria_id coincide con cat.id. Mira la tabla anterior con ese criterio:

Sobreviven tres filas, una por producto. Eso es exactamente lo que hace un JOIN:

Representado como flujo de filas:

Un matiz importante sobre el rendimiento. Que el JOIN se defina así no significa que el motor lo ejecute así. PostgreSQL no materializa 300 filas para tirar 280: usa algoritmos como hash join, merge join o nested loop que van directamente a las parejas que casan, normalmente apoyándose en índices. Es la misma distinción entre orden lógico y plan físico que viste en 02-01, y la estudiarás con EXPLAIN en el módulo 8. Para razonar sobre qué devuelve una consulta, el modelo mental "cartesiano + filtro" es siempre correcto.

Quitado el WHERE de recorte, el JOIN responde por fin a "¿de qué categoría es cada producto?":

20 filas, las mismas que tiene productos. Ese recuento no es casualidad y merece una regla que usarás constantemente:

Cuando unes una tabla con N filas contra otra por una clave foránea obligatoria que apunta a una clave primaria, el resultado tiene exactamente N filas: cada fila encuentra una pareja y solo una. Si el recuento cambia, algo no es como creías.

ON contiene la condición de emparejamiento: la regla que decide qué fila de la izquierda va con qué fila de la derecha.

En el 95 % de los casos que escribirás en tu vida, esa condición es exactamente esta forma:

Es decir: FK = PK. La razón es evidente si recuerdas 01-05: la clave foránea existe precisamente para señalar a una fila concreta de la otra tabla, así que el camino natural entre dos tablas es el que dibuja la propia FK.

Estas son las condiciones de emparejamiento canónicas de TiendaVerde. Consúltalas cada vez que dudes:

Aunque la igualdad FK = PK sea lo habitual, ON admite cualquier expresión booleana, igual que WHERE:

Cuando la condición no es una igualdad se habla de non-equi join. Son minoría, pero existen: rangos de fechas, escalas de precios, comparaciones entre filas de la misma tabla. El caso de p1.id < p2.id lo usarás en la lección 03-06 para generar parejas de productos sin repeticiones.

Antes del estándar SQL-92 no existía la palabra JOIN. Las tablas se listaban separadas por comas en el FROM y la condición de emparejamiento se escribía en el WHERE:

Ambas devuelven lo mismo y PostgreSQL genera el mismo plan para las dos. Pero la antigua tiene cuatro problemas serios:

Regla del curso: siempre JOIN ... ON. El FROM describe cómo se relacionan las tablas; el WHERE describe qué filas nos interesan. Nunca se mezclan. La única excepción admitida es el CROSS JOIN deliberado, que veremos en 03-06.

Este es el motivo práctico por el que la sintaxis de comas se abandonó. Olvida la condición del WHERE:

300 filas = 20 productos × 15 clientes. Y lo peor: no hay ningún error. La consulta se ejecuta, devuelve datos con aspecto plausible y, si la metes en un informe, ese informe estará mal sin que nada lo delate.

El mismo olvido con la sintaxis moderna es imposible de cometer sin darse cuenta:

JOIN exige un ON (o un USING). Si de verdad quieres el producto cartesiano tienes que pedirlo explícitamente con CROSS JOIN, que es una declaración de intenciones que nadie escribe por accidente.

El tamaño del accidente crece muy deprisa:

Esa última fila es la razón por la que un JOIN mal escrito puede tumbar un servidor. En TiendaVerde solo se traduce en un resultado absurdo; en producción, en una llamada a las tres de la madrugada.

Síntoma inconfundible: si una consulta devuelve muchísimas más filas de las que esperabas y los datos parecen repetirse en bucle, cuenta tus condiciones ON. Con N tablas hacen falta N-1 condiciones de emparejamiento. Tres tablas, dos ON. Cinco tablas, cuatro ON.

SQL ofrece dos atajos para escribir menos. Uno es útil con reservas; el otro es una trampa.

Si la columna de emparejamiento tiene el mismo nombre en ambas tablas, USING (columna) sustituye al ON:

USING tiene una propiedad que ON no tiene: fusiona la columna común en una sola, en lugar de devolverla dos veces. Por eso puedes escribirla sin cualificar:

En TiendaVerde USING es casi inservible, y no por casualidad: el esquema sigue la convención de que la clave primaria se llama id y la foránea <tabla>_id. Como productos.id y lineas_pedido.producto_id no se llaman igual, USING no aplica. Solo funciona entre dos tablas hijas que comparten el nombre de la FK, como el ejemplo de arriba.

NATURAL JOIN va un paso más allá: empareja automáticamente por todas las columnas que se llamen igual en ambas tablas, sin que tú digas cuáles.

Cero filas. (COUNT(*) simplemente cuenta las filas del resultado; es una función de agregación y se estudia en 04-04. Aquí la usamos como instrumento de medida, y es la única vez que aparecerá en este módulo.)

¿Por qué cero? Porque productos y categorias comparten dos nombres de columna: id y nombre. NATURAL JOIN construye por su cuenta la condición:

Es decir, exige que el producto y la categoría tengan el mismo identificador y el mismo nombre. Ninguna pareja lo cumple. La consulta no falla, no avisa: devuelve un resultado vacío perfectamente educado.

Y hay algo peor que un resultado vacío: un resultado que cambia solo. Si mañana alguien añade una columna activo a categorias, ese NATURAL JOIN empezará a emparejar también por activo y devolverá otra cosa, sin que nadie haya tocado la consulta.

Regla del curso: NATURAL JOIN está prohibido. Es un atajo que ahorra veinte caracteres a cambio de que el significado de tu consulta dependa de los nombres de columna que alguien elija en el futuro. En este esquema, además, nombre existe en categorias, proveedores, productos, clientes y empleados: la mina está sembrada.

En cuanto hay dos tablas en juego, los nombres de columna pueden repetirse. Y si se repiten, el motor no adivina:

Tanto productos como categorias tienen id y nombre. PostgreSQL no elige por ti: te obliga a cualificar la columna con el nombre (o el alias) de su tabla.

Podrías escribirlo todo con el nombre completo de la tabla:

Funciona, pero es insoportablemente verboso en cuanto hay cuatro tablas. Los alias de tabla resuelven eso:

Fíjate en que aquí hacen falta dos tipos de alias distintos, y conviene no confundirlos:

Sin el alias de columna, el resultado tendría dos columnas llamadas nombre, y ni tú ni tu aplicación sabríais cuál es cuál. Es exactamente el problema que anticipábamos en 02-01 al hablar de SELECT *.

Alias de tabla del curso. Para que todas las consultas del temario se lean igual, fijamos estas abreviaturas y las usaremos siempre:

Y cuando la misma tabla aparezca dos veces (los self join de 03-06), los alias dejan de ser una comodidad para ser obligatorios, y usaremos nombres significativos: empleados AS e y empleados AS jefe, clientes AS c y clientes AS referidor.

Dos detalles de sintaxis:

• El AS de los alias de tabla es opcional: FROM productos p es idéntico a FROM productos AS p. En este curso lo escribimos siempre, por coherencia con los alias de columna.
• Una vez definido el alias, el nombre original deja de ser utilizable. Si escribes FROM productos AS p, no puedes referirte a productos.precio: dará missing FROM-clause entry for table "productos".

Todos los JOIN comparten el mecanismo de la sección 2. Lo que cambia es qué se hace con las filas que no encuentran pareja.

En forma de tabla, con la pregunta típica de TiendaVerde que resuelve cada uno:

A esos cinco se añade el SELF JOIN, que no es un sexto tipo sino una técnica: usar cualquiera de los anteriores para unir una tabla consigo misma, y así recorrer las relaciones reflexivas de empleados.jefe_id y clientes.referido_por_id. También es 03-06.

Un apunte de vocabulario que verás en la documentación: INNER JOIN es el join interno; LEFT, RIGHT y FULL son los joins externos (outer joins), porque conservan filas que quedan "fuera" del emparejamiento. De ahí que su nombre completo sea LEFT OUTER JOIN, RIGHT OUTER JOIN y FULL OUTER JOIN; la palabra OUTER es opcional en los tres.

Las preguntas de negocio rara vez se resuelven con dos tablas. Encadenar es simplemente añadir una línea JOIN ... ON ... por cada tabla nueva, y funciona porque el resultado de un JOIN es a su vez una tabla que puede volver a unirse.

"¿Quién compró cada línea de pedido?" El nombre del cliente no está en lineas_pedido ni es alcanzable en un salto: hay que pasar por pedidos.

(10 primeras de 47 filas.)

Tres tablas, dos condiciones ON, y el recuento sigue siendo 47: el mismo que tiene lineas_pedido. Fíjate en que el nombre del cliente se repite en las tres primeras filas, porque el pedido 1 tiene tres líneas. Eso no es un error: es la consecuencia natural de unir por el lado "muchos" de una relación 1:N, y en 03-02 verás por qué es la causa número uno de las sumas infladas del módulo 4.

(10 primeras de 47 filas.)

Ahí está por fin el detalle de ventas legible: qué se vendió, de qué categoría y por cuánto. En el módulo 4 sumaremos esos importes por categoría y responderemos a "¿qué categoría factura más?"; de momento nos quedamos en las filas de detalle, que es lo que este módulo sabe producir.

Observa cómo se calcula el importe siguiendo la convención de 02-02: se opera con precisión completa dentro del ROUND y se redondea solo al presentar. La línea 6 lo ilustra: 6 * 1.95 * 0.90 = 10.53.

Cómo se construye una cadena, en tres pasos. Este método te evitará casi todos los errores:

1. Localiza el punto de partida: la tabla que contiene el nivel de detalle que quieres (una fila por línea de pedido → lineas_pedido).
2. Traza el camino en el diagrama ER de 01-06 hasta cada dato que necesites, siguiendo las flechas de las claves foráneas.
3. Escribe un JOIN ... ON por cada salto, en el orden del camino, y comprueba el recuento de filas al final.

Aquí llega la ampliación del diagrama que venimos arrastrando desde 02-01, y es la pieza más importante de la lección para lo que viene después.

La pregunta que resuelve es: ¿en qué momento se resuelven los JOIN? Respuesta: dentro del paso FROM, antes de WHERE.

Léelo despacio, porque de aquí salen tres consecuencias que gobiernan todo el módulo:

1. ON y WHERE se ejecutan en momentos distintos. ON actúa mientras se construye el emparejamiento; WHERE actúa después, sobre la tabla ya combinada.

2. En un INNER JOIN esa diferencia no se nota. Poner pe.estado = 'entregado' en el ON o en el WHERE da exactamente el mismo resultado, porque en un INNER JOIN no hay paso 1d: las filas sin pareja se descartan igual. Lo comprobarás en 03-02.

3. En un LEFT JOIN la diferencia es enorme. El paso 1d reintroduce las filas sin pareja después de aplicar el ON, pero antes de aplicar el WHERE. Resultado:

Es el error más frecuente y más difícil de detectar de todo SQL intermedio, y la lección 03-03 lo demuestra con la misma consulta escrita de las dos formas y sus dos resultados distintos. Ten este diagrama a mano cuando llegues allí.

Una nota final sobre el orden dentro del propio FROM: cuando encadenas varios JOIN, se resuelven de izquierda a derecha. A JOIN B JOIN C significa (A JOIN B) JOIN C: primero se une A con B, y el resultado se une con C. Con INNER JOIN puros el orden es indiferente (03-02); con LEFT JOIN encadenados, no lo es en absoluto (03-03).

• Olvidar la condición ON usando la sintaxis de comas. Produce un producto cartesiano silencioso: muchas filas, ningún error. Con N tablas necesitas N-1 condiciones de emparejamiento.
• column reference "id" is ambiguous. Dos tablas del FROM tienen una columna con ese nombre. Cualifícala: p.id, cat.id. Ocurre siempre con id y con nombre en este esquema.
• missing FROM-clause entry for table "productos". Has definido el alias p y luego has escrito productos.precio. Una vez hay alias, el nombre original ya no existe para esa consulta.
• Usar NATURAL JOIN "porque es más corto". Empareja por todas las columnas homónimas, incluidas las que alguien añada mañana. En productos NATURAL JOIN categorias devuelve 0 filas por culpa de nombre.
• Emparejar por la columna equivocada. ON lp.producto_id = pe.id compila perfectamente y devuelve basura: estás comparando un identificador de producto con uno de pedido. Comprueba siempre que ambos lados de la igualdad hablan de la misma entidad.
• Suponer que un JOIN nunca cambia el número de filas. Solo se conserva cuando unes por FK obligatoria contra PK. Si la FK admite NULL, pierdes filas (03-03); si el lado derecho tiene varias filas por cada izquierda, las multiplicas (03-02).
• Mezclar sintaxis antigua y moderna en la misma consulta. FROM a, b JOIN c ON ... es legal y es un campo de minas de precedencia. No lo hagas.
• Consejo: escribe el JOIN antes que el SELECT. Construye primero el FROM con sus cadenas, ejecuta con SELECT * y LIMIT 5 para ver la forma del resultado, y solo entonces elige las columnas.
• Consejo: cuenta las filas después de cada JOIN que añadas. Si añades una tabla y el recuento se dispara, esa tabla tiene varias filas por cada fila anterior. Si cae a cero, tu condición ON no casa nada.
• Consejo: ten abierto el diagrama ER de 01-06. Los JOIN son caminos por ese diagrama. Nadie los memoriza; se leen.

Compras necesita saber qué parte del catálogo depende de proveedores extranjeros. Escribe una consulta que devuelva, solo para los productos cuyo proveedor no es de España: el id y el nombre del producto, su precio, el nombre del proveedor y su país. Ordena por país y, dentro de cada país, por id de producto.

Después responde: ¿por qué la condición sobre el país va en el WHERE y no en el ON?

Te llega esta consulta escrita por un compañero:

1. Reescríbela con sintaxis moderna JOIN ... ON, separando claramente emparejamiento y filtrado.
2. ¿Qué ocurriría exactamente si alguien borrara por accidente la línea pe.cliente_id = c.id en la versión original? Calcula cuántas filas devolvería.

Sin ejecutar nada, predice el número de filas que devuelve cada una de estas consultas y justifica cada predicción en una frase. Después ejecútalas y comprueba.

Solución 1

12 filas de las 20 del catálogo: 8 productos vienen de los dos proveedores españoles (Huerta del Turia y BioSierra Ibérica) y los otros 12 de Alemania, Francia y Portugal.

Por qué la condición va en el WHERE: pr.pais <> 'España' no dice cómo se emparejan las tablas —eso ya lo dice p.proveedor_id = pr.id—, dice qué filas del resultado nos interesan. Es la separación de responsabilidades de la sección 4: ON para emparejar, WHERE para filtrar.

Dicho esto, en este caso concreto ponerla en el ON daría el mismo resultado, porque es un INNER JOIN y los pasos 1c y 2 del orden lógico se comportan igual cuando no hay filas huérfanas que reintroducir. La distinción se vuelve crítica en el LEFT JOIN de 03-03, y por eso conviene coger la costumbre correcta desde ahora.

Solución 2

1. Reescritura moderna:

Los dos pedidos entregados de clientes franceses. La reescritura deja a la vista lo que la versión antigua escondía: una sola condición de emparejamiento y dos de filtrado.

2. Si se borra pe.cliente_id = c.id:

La consulta pasa a ser un producto cartesiano filtrado solo por país y estado. El cálculo:

• Clientes de Francia: 2 (Camille Dubois y Julien Moreau).
• Pedidos con estado entregado: 14.
• Filas resultantes: 2 × 14 = 28.

Y serían 28 filas falsas: cada pedido entregado aparecería asociado a los dos clientes franceses, incluidos los pedidos que en realidad son de Lucía, de Sofia o de Tiago. Ningún error, ningún aviso, un informe completamente inventado. Es exactamente el peligro de la sección 5.

Solución 3

El caso d) es el más instructivo de los cinco y el motivo de que existan las lecciones 03-03 y 03-04: si la dirección te pide "el listado de pedidos con su comercial" y entregas 10 filas de 20, has perdido la mitad del negocio sin enterarte.

Ya tienes el marco conceptual completo del módulo:

• La normalización separa para almacenar sin redundancia; el JOIN recompone para consultar. Son complementarios, no contradictorios.
• Un JOIN es un producto cartesiano filtrado por una condición. Ese modelo mental —combinar todo con todo y quedarse con lo que casa— explica el comportamiento de todos los tipos de JOIN, aunque el motor lo ejecute de forma mucho más eficiente.
• La condición va en ON y casi siempre tiene la forma FK = PK. Tienes la tabla de las once condiciones canónicas de TiendaVerde para consultarla siempre que dudes.
• La sintaxis moderna JOIN ... ON sustituye a la antigua de comas: separa emparejamiento de filtrado, impide el CROSS JOIN accidental y es la única que admite JOIN externos.
• USING solo sirve si las columnas se llaman igual (raro en este esquema) y NATURAL JOIN está prohibido: en productos NATURAL JOIN categorias devuelve 0 filas por culpa de la columna nombre.
• Los alias de tabla son obligatorios en la práctica: sin ellos llegan los column reference "id" is ambiguous. Tienes fijados los del curso: p, cat, pr, c, e, pe, lp, r, d.
• Conoces la panorámica de los cinco tipos y sabes que la única diferencia entre ellos es qué se hace con las filas que no encuentran pareja.
• Sabes encadenar tres o más tablas siguiendo el diagrama ER, con N-1 condiciones ON para N tablas, y tienes los dos caminos que usarás todo el curso: lineas_pedido → pedidos → clientes y lineas_pedido → productos → categorias.
• Y sabes que, en el orden lógico, los JOIN se resuelven dentro del paso FROM, antes del WHERE: de ahí saldrá la diferencia crítica entre poner una condición en ON o en WHERE.

En la lección siguiente, INNER JOIN, bajaremos al detalle del tipo que acabas de usar sin nombrarlo: qué filas conserva, cuáles pierde y por qué. Verás desaparecer a los clientes 13, 14 y 15 al unir clientes con pedidos, y a los 10 pedidos web al unir pedidos con empleados. Esas desapariciones, lejos de ser un fallo, son la definición misma del INNER JOIN, y entenderlas es lo que hace que el LEFT JOIN de 03-03 tenga sentido.