JOINs en SQL: cómo combinar tablas

Un JOIN es la operación de SQL que combina filas de dos o más tablas en una sola consulta, uniéndolas según cómo se relacionan entre sí. Su necesidad surge del propio diseño de las bases de datos relacionales, que reparten los datos en tablas separadas para evitar repetir información: por ejemplo, los datos de los clientes se guardan en una tabla y los pedidos en otra, conectadas mediante claves. Sin embargo, muy a menudo se necesita ver esa información combinada, como obtener la lista de pedidos junto con el nombre del cliente que hizo cada uno, y ahí es donde entra el JOIN, que trae juntas las filas relacionadas de ambas tablas. Todo JOIN incluye una condición, introducida con la palabra ON, que especifica qué columnas deben coincidir para unir dos filas, y que casi siempre expresa la relación entre la clave foránea de una tabla y la clave primaria de la otra, por ejemplo igualando el identificador de cliente que aparece en cada pedido con el identificador del cliente correspondiente. Esta condición es fundamental, porque le indica a la base de datos qué fila de una tabla corresponde a cuál de la otra; si se omitiera, la base de datos no sabría cómo emparejarlas y combinaría todas las filas de una con todas las de la otra, produciendo un resultado gigantesco y sin sentido conocido como producto cartesiano. El JOIN es una de las operaciones más importantes y usadas de SQL, porque es la que permite aprovechar realmente la estructura relacional de los datos, reuniendo la información distribuida en distintas tablas de forma coherente y bajo demanda.

La diferencia entre INNER JOIN y LEFT JOIN está en qué hacen con las filas que no tienen coincidencia en la otra tabla, y es una de las distinciones más importantes y con más consecuencias prácticas en SQL. El INNER JOIN devuelve únicamente las filas que tienen coincidencia en ambas tablas según la condición de unión, de modo que las filas que no encuentran pareja en la otra tabla quedan excluidas del resultado. En el ejemplo de clientes y pedidos, un INNER JOIN entre ambos devolvería solo los clientes que sí tienen al menos un pedido, dejando fuera tanto a los clientes sin pedidos como, en teoría, a cualquier pedido sin cliente. El LEFT JOIN, en cambio, devuelve todas las filas de la tabla izquierda, que es la que aparece en la cláusula FROM, y les añade las coincidencias de la tabla derecha cuando existen, rellenando con valores vacíos las columnas de la derecha cuando no hay coincidencia. En el mismo ejemplo, un LEFT JOIN de clientes con pedidos devolvería todos los clientes, tengan pedidos o no, mostrando la información del pedido para los que sí tienen y valores vacíos en las columnas de pedido para los que no. La consecuencia práctica es enorme: si se necesita un listado completo de todos los clientes, por ejemplo para un informe, y por error se usa un INNER JOIN en lugar de un LEFT JOIN, los clientes sin pedidos desaparecen silenciosamente del resultado, dando la falsa impresión de que hay menos clientes de los que realmente existen. Por eso, al escribir un JOIN, la pregunta clave que hay que hacerse siempre es qué se quiere que ocurra con las filas que no tienen pareja: si deben conservarse, hace falta un LEFT JOIN; si solo interesan las coincidencias, un INNER JOIN.

La condición ON de un JOIN especifica cómo se relacionan las dos tablas que se quieren combinar, es decir, qué columnas deben coincidir para que una fila de una tabla se una con una fila de la otra. Es la parte que le dice a la base de datos el criterio de emparejamiento, y sin ella el JOIN no tiene sentido. En la inmensa mayoría de los casos, la condición ON expresa la relación entre claves: iguala la clave foránea de una tabla con la clave primaria de la otra, por ejemplo indicando que el identificador de cliente que aparece en la tabla de pedidos debe coincidir con el identificador del cliente en la tabla de clientes. De este modo, cada pedido se une con el cliente concreto al que pertenece. La importancia de la condición ON es doble. Por un lado, es lo que produce resultados correctos y con significado, uniendo exactamente las filas que están realmente relacionadas. Por otro lado, su omisión provoca uno de los errores clásicos de SQL: si se combinan dos tablas sin especificar la condición de unión, la base de datos empareja cada fila de la primera con todas las filas de la segunda, generando el llamado producto cartesiano, cuyo resultado tiene un número de filas igual al producto de las filas de ambas tablas y carece de sentido práctico, además de poder ser enorme y pesado. Por eso es fundamental incluir siempre una condición ON adecuada, y asegurarse de que relaciona las columnas correctas, es decir, las que efectivamente representan el vínculo entre las tablas, y no dos campos cualesquiera que casualmente pudieran compararse.

El RIGHT JOIN y el FULL JOIN son los otros dos tipos principales de JOIN, que completan las posibilidades de qué hacer con las filas sin coincidencia. El RIGHT JOIN es el simétrico del LEFT JOIN: devuelve todas las filas de la tabla derecha, es decir, la que se une mediante la cláusula JOIN, y les añade las coincidencias de la tabla izquierda cuando existen, rellenando con valores vacíos donde no hay pareja. En la práctica, el RIGHT JOIN se usa mucho menos que el LEFT JOIN, porque cualquier consulta con RIGHT JOIN se puede reescribir como un LEFT JOIN simplemente intercambiando el orden de las tablas, y a la mayoría de la gente le resulta más natural pensar en términos de conservar todas las filas de la tabla principal, que se coloca a la izquierda. El FULL JOIN, también llamado FULL OUTER JOIN, es el más inclusivo de todos: devuelve todas las filas de ambas tablas, coincidan o no, de modo que combina las coincidencias donde las hay y conserva además tanto las filas de la izquierda sin pareja en la derecha como las de la derecha sin pareja en la izquierda, rellenando con vacíos en el lado que falte en cada caso. El FULL JOIN es útil cuando se quiere una visión completa que no descarte ninguna fila de ninguna de las dos tablas, por ejemplo para detectar registros no emparejados en ambos sentidos, aunque también se usa con menos frecuencia que INNER y LEFT, y conviene saber que no todas las bases de datos lo soportan de forma nativa. En conjunto, INNER y LEFT son con diferencia los más habituales en el día a día, mientras que RIGHT y FULL cubren casos más específicos.

Encontrar las filas de una tabla que no tienen ninguna coincidencia en otra tabla es una necesidad muy habitual, como obtener la lista de clientes que nunca han hecho un pedido, y se resuelve con una técnica elegante que combina un LEFT JOIN con un filtro sobre los valores vacíos. La idea es la siguiente: se hace un LEFT JOIN de la tabla de la que se quieren todas las filas, por ejemplo clientes, con la tabla en la que se busca la ausencia de coincidencia, por ejemplo pedidos. Como el LEFT JOIN conserva todos los clientes y rellena con valores vacíos las columnas de pedido para aquellos clientes que no tienen ninguno, los clientes sin pedidos se distinguen precisamente porque las columnas provenientes de la tabla de pedidos quedan vacías. Por tanto, basta con añadir una condición que filtre quedándose solo con las filas en las que una columna de la tabla derecha, idealmente su clave primaria u otra columna que nunca sería vacía en una coincidencia real, tiene valor vacío. El resultado son exactamente los clientes que no encontraron ninguna pareja en la tabla de pedidos, es decir, los que no tienen pedidos. Esta técnica, conocida a veces como anti-join, es muy útil para todo tipo de búsquedas de ausencia: productos que nunca se han vendido, usuarios que no han iniciado sesión, registros que no han sido procesados, y muchos otros casos. Es un buen ejemplo de cómo, entendiendo bien cómo funciona el LEFT JOIN y el comportamiento de los valores vacíos, se pueden resolver de forma sencilla consultas que a primera vista parecerían complicadas.

Que un JOIN devuelva lo que parecen filas repetidas suele ser consecuencia natural de las relaciones de uno a muchos entre las tablas, y no necesariamente un error, aunque puede sorprender y conviene entenderlo bien. Cuando se unen dos tablas en las que una fila de la primera se relaciona con varias filas de la segunda, el JOIN produce una fila de resultado por cada combinación válida, de modo que los datos de la fila del lado uno aparecen repetidos tantas veces como filas relacionadas haya en el lado muchos. Por ejemplo, si un cliente tiene tres pedidos y se hace un JOIN de clientes con pedidos, el nombre de ese cliente aparecerá tres veces en el resultado, una por cada pedido, porque cada fila del resultado representa la combinación de ese cliente con uno de sus pedidos. Esto es el comportamiento correcto y esperado del JOIN, pero tiene una implicación importante que hay que tener presente, especialmente al hacer cálculos: si se intenta sumar o contar algo del lado uno directamente sobre el resultado de un JOIN uno a muchos, se corre el riesgo de contar valores duplicados y obtener totales inflados. Por ejemplo, sumar un dato del cliente que se ha repetido por cada pedido daría un resultado erróneo. Para manejar correctamente estas situaciones se recurre a técnicas como agrupar los resultados con las funciones de agregación adecuadas, usar la eliminación de duplicados cuando corresponde, o estructurar la consulta con subconsultas, según el objetivo. Lo esencial es reconocer que la aparente repetición refleja la estructura real de las relaciones entre los datos, y planificar la consulta teniendo en cuenta la multiplicidad que introducen las relaciones de uno a muchos.