El INNER JOIN es el JOIN por defecto, el que ya usaste sin nombrarlo en la lección anterior y el que escribirás en ocho de cada diez consultas de tu vida profesional. Su regla es de una simplicidad absoluta: solo sobreviven las filas que encuentran pareja a ambos lados. Todo lo demás desaparece, en silencio y sin aviso.

Y ahí está la trampa. Un INNER JOIN nunca da error por perder filas; simplemente te devuelve menos de las que esperabas. En esta lección aprenderás no solo a escribirlo, sino a predecir cuántas filas devuelve y por qué, que es la habilidad que distingue a quien entiende los JOIN de quien los copia. Verás desaparecer a tres clientes de TiendaVerde y a la mitad de sus pedidos, y entenderás que esas desapariciones son la definición misma del operador.

1. INNER JOIN frente a JOIN a secas
2. El diagrama de conjuntos
3. Ejemplos progresivos sobre TiendaVerde
4. La consulta canónica de cuatro tablas
5. Qué filas se pierden y por qué
6. Condiciones adicionales: ON frente a WHERE
7. Claves no únicas y la multiplicación de filas
8. El orden de las tablas no cambia el resultado
9. Errores Comunes y Consejos
10. Ejercicios
11. Conclusión

Las dos formas siguientes son exactamente la misma consulta:

INNER es opcional porque el estándar SQL define el JOIN sin calificar como interno. Es lo contrario de lo que ocurre con LEFT OUTER JOIN, donde lo opcional es OUTER.

¿Cuál escribir? Hay dos escuelas. Una prefiere JOIN por brevedad; la otra prefiere INNER JOIN porque, en una consulta que mezcla varios tipos, ver la palabra INNER junto a un LEFT deja explícita la intención y evita que alguien piense que se olvidó un modificador.

Convención del curso: escribiremos JOIN cuando toda la consulta sea interna, y INNER JOIN explícito cuando conviva con un LEFT, un RIGHT o un FULL en la misma consulta. Es la práctica más extendida en equipos profesionales.

La forma clásica de visualizar los JOIN es con dos conjuntos que se solapan. El INNER JOIN devuelve solo la intersección:

Y como flujo de filas, retomando el modelo mental de 03-01:

Ese cuadro rojo —"se descartan a ambos lados"— es todo lo que hay que recordar del INNER JOIN. Las lecciones 03-03, 03-04 y 03-05 consisten precisamente en recuperar lo que aquí se tira.

Ya lo viste en 03-01; lo recuperamos como punto de partida, ahora ampliado con el proveedor. Tres tablas, dos ON:

Fíjate en un detalle que solo es posible con JOIN: hemos filtrado por el nombre de la categoría, no por su id. Antes de este módulo habrías tenido que buscar a mano que "Cosmética natural" es la categoría 2 y escribir WHERE categoria_id = 2. Ahora la consulta se lee como se piensa.

La pregunta con la que cerramos el módulo 2: quién hizo cada pedido.

20 filas, las mismas que tiene pedidos. Ahí está por fin "Camille Dubois" donde antes había un 9.

Dos observaciones:

• Los nombres se repiten: Lucía Martínez Soler aparece tres veces porque hizo tres pedidos (1, 5 y 15). Es normal: unimos por el lado "muchos" de la relación 1:N.
• La concatenación c.nombre || ' ' || c.apellidos es la de 02-02, con su advertencia sobre NULL incluida. Aquí es segura porque ambas columnas son NOT NULL.

(10 primeras de 47 filas.)

Aquí se ve algo que en el módulo 2 solo podíamos intuir: la línea 1 tiene precio_unitario 11.95, mientras que el aceite cuesta hoy 12.50 €. Es el precio histórico del que hablaba 01-06. Un error clásico sería calcular el importe con p.precio en lugar de con lp.precio_unitario: obtendrías 25.00 € en vez de 23.90 € y estarías reescribiendo la historia comercial de la empresa.

Regla del curso: el importe de una línea se calcula siempre con lp.precio_unitario, nunca con p.precio. La tabla productos dice cuánto cuesta hoy; lineas_pedido dice cuánto se cobró entonces.

Esta es la consulta más importante del curso. Responde a "¿qué compró cada cliente y por cuánto?" y necesita cuatro tablas: el detalle está en lineas_pedido, el cliente cuelga de pedidos y el nombre del producto de productos.

Observa la forma del camino: no es una cadena lineal, es una estrella con lineas_pedido en el centro. Desde ella salen dos ramas: una hacia el pedido y su cliente, otra hacia el producto. Eso es normal cuando la tabla de partida tiene varias claves foráneas.

(12 primeras de 47 filas.)

47 filas: una por línea de pedido. Guarda esta consulta, porque es la base de casi todo lo que viene después. En el módulo 4 le añadirás GROUP BY c.id y SUM(importe) para responder "¿cuánto ha gastado cada cliente?"; en el módulo 7 la usarás como subconsulta; en el módulo 10 la convertirás en una vista. El esqueleto no cambia.

Cuatro tablas, tres condiciones ON. Vuelve a comprobarse la regla de 03-01: N tablas, N-1 emparejamientos.

Llegamos al corazón de la lección. Un INNER JOIN descarta silenciosamente las filas sin pareja, y en TiendaVerde eso tiene dos consecuencias muy visibles.

clientes tiene 15 filas. Veamos quiénes sobreviven a un INNER JOIN con pedidos:

12 filas, no 15. Faltan los clientes 13 (Núria Bosch Ferrer), 14 (Hugo Iglesias Pardo) y 15 (Inés Carrasco Vega). ¿Por qué? Porque ninguno ha hecho un pedido, así que en el producto cartesiano no existe ninguna combinación en la que pe.cliente_id valga 13, 14 o 15. La condición ON no las encuentra y desaparecen.

El balance de recuentos:

Las tres cifras son distintas y las tres son correctas: responden a preguntas distintas. Si te piden "el listado de clientes con su actividad" y entregas 12 de 15, has borrado del informe a tres personas.

Aviso: ese DISTINCT es exactamente el síntoma del que hablaba 02-04. Aparece aquí porque estamos usando una herramienta —el INNER JOIN— que no es la adecuada para la pregunta "qué clientes han comprado". La herramienta correcta llega en 03-03.

El mismo fenómeno, desde el otro lado. pedidos.empleado_id admite NULL porque los pedidos web no llevan comercial asignado:

10 filas de 20. Han desaparecido los pedidos 1, 3, 5, 7, 9, 11, 13, 15, 17 y 19: todos los que tienen empleado_id IS NULL.

El mecanismo es el que viste en 02-03 con empleado_id = NULL: NULL no es igual a nada, ni siquiera a otro NULL. La condición ON pe.empleado_id = e.id se evalúa a NULL (que no es TRUE) para esas diez filas, así que ninguna pareja las salva.

Y aquí está el daño real: la mitad de la facturación de TiendaVerde ha desaparecido del informe. Si la dirección pregunta "¿cuántos pedidos hemos tenido este año?" y respondes con esta consulta, tu respuesta será la mitad de la verdad.

Resumiendo, un INNER JOIN pierde filas por dos motivos:

En ambos casos la respuesta es la misma familia de operadores, y por eso las lecciones 03-03, 03-04 y 03-05 existen. El INNER JOIN no está mal: simplemente responde a la pregunta "dame lo que casa", y a veces la pregunta del negocio es otra.

Nada impide poner condiciones extra dentro del ON, más allá del emparejamiento. Estas dos consultas piden lo mismo: los pedidos de clientes portugueses.

Resultados idénticos. Y no es casualidad: en un INNER JOIN son siempre equivalentes. Vuelve al diagrama del orden lógico de 03-01 y entenderás por qué. En un JOIN interno no existe el paso 1d —no se reintroduce ninguna fila sin pareja—, así que filtrar durante el emparejamiento o justo después produce el mismo conjunto.

Si son equivalentes, ¿dónde ponerlas? Por legibilidad:

Y ahora el aviso más importante de esta lección: esta equivalencia es EXCLUSIVA del INNER JOIN. En un LEFT JOIN, mover una condición del ON al WHERE cambia el resultado, y lo cambia de una forma que parece un fallo de datos y no un fallo de consulta. La lección 03-03 lo demuestra con la misma pregunta escrita de las dos maneras y sus dos resultados distintos. Coge desde ya la costumbre de separar emparejamiento y filtrado: cuando llegues al LEFT JOIN, esa costumbre te salvará.

Hasta ahora todos los JOIN de la lección han conservado el número de filas de la tabla de partida. Eso ocurre cuando unes desde el lado "muchos" hacia el lado "uno" (de productos a categorias, de pedidos a clientes): cada fila encuentra exactamente una pareja.

Al revés, la cosa cambia.

Tres pedidos han producido ocho filas. El pedido 1 aparece tres veces (tiene tres líneas), el 2 dos veces y el 3 tres veces. Los datos de cabecera —fecha, estado, y también gastos_envio si lo hubiéramos pedido— se repiten en cada línea.

La regla general:

Al unir por una columna no única en el lado derecho, cada fila de la izquierda se duplica tantas veces como parejas encuentre.

Esto parece inofensivo mientras solo miras filas de detalle. Se vuelve peligroso en el módulo 4, cuando empieces a sumar. Imagina esta consulta:

Los gastos de envío del pedido 1 son 4,95 € una vez, pero después del JOIN esa cifra aparece en tres filas. La suma daría 14,85 € solo para ese pedido: el triple de lo real. Y no habrá ningún error, ningún aviso, solo un número equivocado en un informe de dirección.

Lo mismo ocurriría al sumar salario tras unir empleados con pedidos, o al contar clientes tras unir clientes con lineas_pedido.

Aprende a detectarlo ahora: después de cada JOIN que añadas, pregúntate "¿cuántas filas de la derecha puede haber por cada fila de la izquierda?". Si la respuesta es "más de una", cualquier valor de la izquierda que sumes después estará multiplicado. En el módulo 4 verás las técnicas para evitarlo; de momento basta con reconocer el síntoma.

Un truco de verificación que puedes aplicar hoy mismo: si el recuento de filas de tu consulta coincide con el de la tabla de detalle (47 para lineas_pedido), estás en el nivel de granularidad correcto para trabajar con importes de línea.

En un INNER JOIN, A JOIN B y B JOIN A devuelven el mismo conjunto de filas. La operación es conmutativa.

Ambas devuelven las mismas 20 filas. Lo único que puede cambiar es el orden de las columnas si usas SELECT *, y el orden de las filas si no pones ORDER BY (lo de siempre desde 02-01).

Con tres o más tablas también es asociativa: (A JOIN B) JOIN C equivale a A JOIN (B JOIN C), siempre que las condiciones ON estén bien puestas.

Que sea conmutativo tiene dos consecuencias prácticas:

1. Escribe las tablas en el orden en que se entiende la pregunta. Si el informe es "pedidos con su cliente", empieza por pedidos. Si es "clientes y sus pedidos", empieza por clientes. El resultado es el mismo y la consulta se lee mejor.
2. El optimizador no te hace caso. PostgreSQL reordena libremente los INNER JOIN para elegir el plan más barato: puede empezar por la tabla más pequeña, o por la que tenga el filtro más selectivo, con independencia de cómo lo escribas. Tu orden es documentación para humanos, no una instrucción para el motor. (Lo verás en el módulo 8.)

Y una advertencia para lo que viene. El LEFT JOIN no es conmutativo: A LEFT JOIN B y B LEFT JOIN A devuelven cosas distintas. Ahí el orden en que escribes las tablas es parte del significado, no del estilo.

• Dar por hecho que el INNER JOIN conserva todas las filas. Pierde las que no casan a ninguno de los dos lados, sin decir nada. Comprueba el recuento contra la tabla de partida.
• Olvidar que una FK con NULL nunca casa. Los 10 pedidos web desaparecen al unir con empleados. NULL = 4 no es falso: es NULL, y NULL no es TRUE.
• Calcular el importe con p.precio en vez de lp.precio_unitario. Devuelve el precio de hoy aplicado a una venta de hace un año. Con la línea 1 la diferencia es de 1,10 €; con un catálogo real, de miles de euros.
• Sumar valores de cabecera después de unir con el detalle. SUM(pe.gastos_envio) tras JOIN lineas_pedido cuenta cada pedido tantas veces como líneas tenga. Es la causa nº 1 de informes inflados.
• Poner el DISTINCT como parche. Si necesitas DISTINCT para arreglar un JOIN, casi siempre el JOIN es el que está mal planteado (02-04). Piensa qué granularidad quiere de verdad la pregunta.
• Creer que la equivalencia ON/WHERE es general. Solo vale para INNER JOIN. En LEFT JOIN cambia el resultado (03-03).
• Emparejar por columnas del tipo correcto pero del concepto equivocado. ON lp.producto_id = pe.id no da error, compara enteros con enteros, y devuelve datos sin sentido.
• Consejo: valida cada JOIN por separado. Escribe primero FROM lineas_pedido lp JOIN pedidos pe ON ... con LIMIT 5, comprueba, y solo entonces añade la tercera tabla. Depurar una consulta de cinco tablas escrita de una tacada es un suplicio.
• Consejo: memoriza los tres recuentos de TiendaVerde. 20 productos, 20 pedidos, 47 líneas. Si una consulta de detalle no devuelve 47 filas, sabes de inmediato que algo pasa.
• Consejo: nombra los alias de columna cuando unas tablas con columnas homónimas. c.nombre AS cliente y p.nombre AS producto evitan que el resultado tenga dos columnas llamadas nombre.

El equipo de producto quiere revisar las opiniones recibidas. Escribe una consulta que devuelva, para cada reseña: su id, el nombre del producto reseñado, el nombre completo de quien la escribió, la puntuación y la fecha. Ordena por id de reseña.

Después responde: ¿cuántas filas devuelve, y por qué ese número no coincide con el número de productos del catálogo?

Administración necesita el detalle de las devoluciones. Escribe una consulta que muestre, para cada devolución: su id, la fecha, el importe, el motivo, el id y el estado del pedido devuelto, y el nombre completo del cliente afectado.

Indica cuántas tablas has necesitado, cuántas condiciones ON y por qué.

Camille Dubois (cliente 9) ha llamado reclamando el detalle de todo lo que ha comprado. Usando la consulta canónica de cuatro tablas de la sección 4, obtén su historial completo: pedido, fecha, estado del pedido, producto, cantidad e importe de la línea.

Después responde a estas dos preguntas:

1. ¿Cuántas filas devuelve y cuántos pedidos representan?
2. Si en lugar de INNER JOIN entre pedidos y clientes hubieras unido pedidos con empleados, ¿aparecerían los mismos pedidos de Camille? Razona la respuesta mirando los datos.

Solución 1

12 filas, exactamente las de resenas. Partimos de esa tabla y sus dos claves foráneas (producto_id, cliente_id) son obligatorias y válidas: cada reseña encuentra un producto y un cliente, uno y solo uno.

Por qué no coincide con los 20 productos: porque la consulta va de reseñas a productos, no al revés. Solo aparecen los 9 productos distintos que tienen alguna reseña (el aceite, el arroz y la crema aparecen dos veces cada uno). Los 11 productos sin ninguna reseña —entre ellos el desodorante y las cápsulas de espirulina— no existen para esta consulta. Para verlos habría que partir de productos y usar un LEFT JOIN: es justo lo que hace la lección siguiente.

Solución 2

Tres tablas y dos condiciones ON, siguiendo la regla N-1 de 03-01. Hacen falta tres porque el cliente no es alcanzable desde devoluciones en un solo salto: devoluciones solo conoce pedido_id, y es pedidos quien conoce cliente_id. El camino obligatorio es devoluciones → pedidos → clientes.

Un detalle que valida los datos: la devolución 2 vale 34,02 €, exactamente el importe de la línea 24 (2 unidades de crema facial a 18,90 € con 10 % de descuento). No es casualidad: se devolvió ese producto concreto del pedido de Camille.

Solución 3

1. 4 filas que representan 2 pedidos: el 10 (entregado, dos líneas) y el 20 (pendiente, dos líneas). Es la multiplicación de filas de la sección 7 en acción: el número de filas es el de líneas, no el de pedidos. Si quisieras el número de pedidos de Camille, esta consulta no es la herramienta: te haría falta COUNT(DISTINCT pe.id) del módulo 4.

2. No. El pedido 10 tiene empleado_id = 4 (Óscar Peris Blasco) y aparecería; el pedido 20 tiene empleado_id = 6 (Marc Estévez Roig) y también. En este caso concreto sí saldrían los dos... pero es pura suerte: ambos pedidos de Camille tienen comercial asignado. Prueba con Lucía Martínez Soler (cliente 1), cuyos tres pedidos —1, 5 y 15— son todos web con empleado_id IS NULL: un INNER JOIN con empleados haría desaparecer el 100 % de su historial. Ese es el peligro que motiva la lección siguiente.

El INNER JOIN ya no tiene secretos:

• JOIN e INNER JOIN son lo mismo. El curso usa JOIN en consultas puramente internas e INNER JOIN explícito cuando conviven varios tipos.
• Devuelve solo la intersección: las filas que encuentran pareja a ambos lados. Todo lo que no casa se descarta en silencio.
• Sabes escribir cadenas de tres y cuatro tablas y tienes la consulta canónica de detalle de ventas (lineas_pedido + pedidos + clientes + productos, 47 filas), que reutilizarás en los módulos 4, 7 y 10.
• Sabes qué se pierde: los clientes 13, 14 y 15 al unir clientes con pedidos (12 clientes de 15), y los 10 pedidos web al unir pedidos con empleados (10 filas de 20). Las dos causas son la FK con NULL y la ausencia de fila hija.
• En un INNER JOIN, poner una condición extra en ON o en WHERE es equivalente; en un LEFT JOIN no lo será, y esa es la trampa de la próxima lección.
• Unir hacia el lado "muchos" multiplica filas: 20 pedidos se convierten en 47 al añadir lineas_pedido. Es la causa número uno de las sumas infladas que verás en el módulo 4.
• El INNER JOIN es conmutativo y asociativo: el orden de las tablas es cuestión de legibilidad, no de significado. El LEFT JOIN no lo será.

En la lección siguiente, LEFT JOIN, recuperaremos todo lo que aquí hemos tirado. Volverán Núria, Hugo e Inés con sus pedidos vacíos; volverán las velas de soja, el desodorante y la espirulina que nadie ha comprado nunca; volverán los diez pedidos web con su comercial a NULL. Aprenderás el patrón anti-join para responder directamente a "¿qué clientes no han comprado nunca?" y verás, con la misma consulta escrita de dos formas, por qué colocar una condición en ON o en WHERE deja de ser indiferente.