Configura dos tablas, elige el tipo de JOIN y observa cómo se combinan las filas con diagrama de Venn animado, líneas de coincidencia y consulta SQL generada.
| empleados.id_dept | empleados.nombre | departamentos.id | departamentos.departamento |
|---|---|---|---|
| 10 | Ana López | 10 | Ventas |
| 20 | Bruno Pérez | 20 | IT |
Operaciones de unión de tablas
| Tipo | Qué incluye | NULLs | Cuándo usar | Ejemplo casual |
|---|---|---|---|---|
| INNER JOIN | Solo filas con coincidencia en ambas tablas | Nunca | Cuando solo importan los registros emparejados | Personas que tienen pasaporte Y visado vigente |
| LEFT OUTER | Todo A + coincidencias de B | En columnas de B sin pareja | Listar todo A, marcando si tiene relación con B | Todos los empleados, con su departamento si lo tienen |
| RIGHT OUTER | Todo B + coincidencias de A | En columnas de A sin pareja | Lo mismo que LEFT pero invertido (poco usado) | Todos los departamentos, con sus empleados si los tienen |
| FULL OUTER | Todo A + Todo B + coincidencias | En ambos lados según falte | Auditoría: detectar registros huérfanos en ambos lados | Comparar inventario físico vs sistema, ver discrepancias |
| CROSS JOIN | Producto cartesiano (A × B) | Nunca (no hay condición) | Generar combinaciones (calendarios, matrices, tests) | Cada talla con cada color de una camiseta |
facturas LEFT JOIN clientes: ver todas las facturas, incluso las huérfanas con cliente borrado (aparecerán con cliente NULL).
LEFT JOIN es ideal para detectar registros huérfanos sin perder ninguna fila.
productos INNER JOIN stock: solo productos con stock registrado. Ignora artículos descatalogados o sin alta en almacén.
INNER JOIN garantiza que no aparezcan productos sin información completa.
empleados FULL OUTER JOIN departamentos: ver empleados sin departamento y departamentos sin empleados de un solo vistazo.
FULL OUTER es la herramienta de auditoría por excelencia.
fechas CROSS JOIN salas: combinar todos los días del mes con todas las salas para crear una matriz de disponibilidad.
CROSS JOIN es perfecto para crear todas las combinaciones posibles.
INNER JOIN solo devuelve filas que coinciden en ambas tablas. OUTER JOIN (LEFT, RIGHT, FULL) además devuelve filas sin pareja, rellenando con NULL las columnas del lado contrario.
Regla rápida: si necesitas ver registros huérfanos, usa OUTER. Si solo te interesan emparejamientos limpios, usa INNER.
Devuelve filas_A × filas_B. Si A tiene 1.000 filas y B tiene 1.000, el resultado son 1.000.000 de filas. En tablas grandes puede colgar el servidor o agotar memoria.
Usa CROSS JOIN solo con tablas pequeñas y conscientemente, nunca por accidente al olvidar la cláusula ON.
Funcionalmente son simétricos: A LEFT JOIN B es equivalente a B RIGHT JOIN A. La convención es escribir siempre LEFT para mantener consistencia y leer la consulta de izquierda a derecha.
En la práctica casi nadie usa RIGHT JOIN. Reescribe siempre con LEFT.
Si la clave del JOIN se repite en alguna tabla, el resultado se multiplica. Por ejemplo, si una clave aparece 2 veces en A y 3 veces en B, esa clave generará 6 filas en el resultado.
Si te aparecen muchas más filas de las esperadas, casi seguro hay duplicados en una de las tablas.
No. PostgreSQL, SQL Server, Oracle y SQLite (3.39+) lo soportan. MySQL no lo soporta de forma nativa; hay que simularlo con UNION de un LEFT JOIN y un RIGHT JOIN excluyendo la intersección.
Antes de usar FULL OUTER, comprueba la documentación de tu motor.
No exactamente. NATURAL JOIN une automáticamente por todas las columnas con el mismo nombre en ambas tablas, sin que tú las especifiques. Es cómodo pero peligroso: si añaden una columna con el mismo nombre, la consulta cambia de significado silenciosamente.
Mejor usa siempre INNER JOIN ... ON explícito. Es más verboso pero robusto.
Localiza la clave primaria (PK) de una tabla y la clave foránea (FK) que apunta a ella en la otra. Ese es el ON de tu JOIN.
¿Solo coincidencias? INNER. ¿Todo A aunque no haya pareja? LEFT. ¿Todo de ambos lados? FULL OUTER. ¿Combinaciones puras? CROSS.
Usa alias cortos (e para empleados, d para departamentos) y prefija siempre las columnas: e.nombre, d.nombre. Evita ambigüedad.
Antes de ejecutar sobre millones de filas, prueba con LIMIT 10 y revisa que el resultado tiene sentido. Si hay 100 filas donde esperabas 10, investiga duplicados.
Compara COUNT(*) antes y después del JOIN. En un INNER JOIN bien hecho con FK válida, no debe perderse ni multiplicarse el conteo principal.
Evita NATURAL JOIN y USING. ON tabla1.id = tabla2.id_externo es autoexplicativo y robusto frente a cambios de esquema.
FROM empleados e JOIN departamentos d hace consultas largas legibles y evita ambigüedad en columnas.
Sin índices en las claves del JOIN, la consulta hará scan completo. Las FKs suelen indexarse automáticamente, pero verifícalo.
Para LEFT JOIN, filtrar la tabla derecha en el ON conserva las filas huérfanas; filtrar en WHERE las elimina. Es un error clásico.
EXPLAIN SELECT ... muestra el plan de ejecución y avisa si el SGBD hará un nested loop sobre tablas enormes.
Si esperas N filas y obtienes 10·N, casi seguro hay duplicados. Si obtienes N/3, algo se está filtrando que no debería.