Cruzar tablas con JOIN

Las tablas no viven solas

Una reserva no guarda el nombre del cliente: guarda su cliente_id, que apunta a la tabla clientes. Así se evita repetir datos. Para verificar la reserva completa —con el nombre real del cliente— hay que unir ambas tablas. Eso es un JOIN.

INNER JOIN: lo que coincide en ambas

SELECT r.id, r.fecha, r.total, c.nombre, c.email
FROM reservas r
INNER JOIN clientes c ON r.cliente_id = c.id
WHERE r.estado = 'confirmada';

Lee así: "trae reservas y, por cada una, el cliente cuyo id coincide con su cliente_id". El r y el c son alias para no repetir el nombre largo de la tabla. El INNER JOIN devuelve solo las filas con correspondencia en ambas tablas.

LEFT JOIN: encontrar lo que falta

Aquí está el superpoder de QA. Un LEFT JOIN trae todas las filas de la tabla izquierda, aunque no tengan pareja en la derecha; donde no hay pareja, las columnas quedan en NULL. Eso te deja cazar huérfanos:

-- Reservas cuyo cliente no existe (integridad rota)
SELECT r.*
FROM reservas r
LEFT JOIN clientes c ON r.cliente_id = c.id
WHERE c.id IS NULL;

Si esa consulta devuelve filas, encontraste un bug grave: reservas apuntando a clientes borrados o inexistentes. Es un defecto que la UI casi nunca muestra (revienta o esconde la reserva), pero que en la base salta a la vista.

El patrón mental

• INNER JOIN → "muéstrame lo que está bien relacionado" (para verificar datos completos).
• LEFT JOIN + IS NULL → "muéstrame lo que quedó sin pareja" (para cazar integridad rota).

Con estos dos patrones verificas relaciones entre cualquier par de tablas: pedidos↔productos, pagos↔reservas, usuarios↔roles.

Comprueba lo aprendido en el quiz y caza huérfanos en el reto.