JOIN y control de duplicaciones

Objetivo

Relacionar entidades sin inflar métricas.

Explicación

Un JOIN combina filas por una condición. El riesgo principal no es la sintaxis sino el cardinality: si ambos lados tienen varias filas por clave, el JOIN multiplica registros. Antes de unir, conoce el grain de cada tabla. En un equipo de datos, SQL no se evalúa sólo por devolver filas: debe responder una pregunta de negocio, conservar el grain correcto y permitir que otra persona valide el resultado. Esta práctica usa el ecommerce del curso para obligarte a reconciliar conteos y totales, igual que harías antes de publicar una métrica en un dashboard. Los JOIN son una de las fuentes más frecuentes de dobles conteos. Antes de sumar una métrica debes conocer la cardinalidad de cada lado y comprobar si la unión cambia el número de filas esperado. Para trabajar JOIN y control de duplicaciones de forma profesional, no te quedes con el ejemplo: identifica la entrada, ejecuta el caso base, provoca al menos un caso incorrecto y compara el resultado con un control independiente. En este laboratorio el criterio de salida es concreto: Con customers único por id, 1 pedido produce 1 fila. Con duplicado, los pedidos de ese cliente se multiplican. La verificación principal será: Compara COUNT(*) antes/después y COUNT(DISTINCT order_id). Si no puedes explicar por qué pasa esa comprobación, vuelve al paso anterior antes de continuar.

Contexto profesional

En un equipo de datos, SQL no se evalúa sólo por devolver filas: debe responder una pregunta de negocio, conservar el grain correcto y permitir que otra persona valide el resultado. Esta práctica usa el ecommerce del curso para obligarte a reconciliar conteos y totales, igual que harías antes de publicar una métrica en un dashboard. Los JOIN son una de las fuentes más frecuentes de dobles conteos. Antes de sumar una métrica debes conocer la cardinalidad de cada lado y comprobar si la unión cambia el número de filas esperado.

Ejemplo real

SELECT o.order_id,c.country,o.amount
FROM orders o
LEFT JOIN customers c ON o.customer_id=c.customer_id;

Archivos o datos de entrada

• data/ecommerce_customers.csv
• data/ecommerce_orders.csv

Práctica guiada

Comprueba que el número de filas sigue siendo igual al de orders.

Laboratorio paso a paso

• Prepara el entorno y localiza los datos/archivos de entrada: data/ecommerce_customers.csv, data/ecommerce_orders.csv. Antes de modificar nada, anota el número de filas, columnas u objetos que esperas usar.
• Reproduce el ejemplo real de la lección y guarda la salida. No avances hasta poder explicar qué hace cada bloque relacionado con «JOIN y control de duplicaciones».
• Ejecuta la práctica guiada: Comprueba que el número de filas sigue siendo igual al de orders. Documenta el comando, consulta o acción exacta y el resultado obtenido.
• Resuelve el reto sin mirar la solución: Crea una copia de customers con un customer_id duplicado y observa cómo crece el JOIN. Si falla, registra el mensaje de error y formula una hipótesis antes de cambiar código.
• Compara tu resultado con el criterio esperado: Con customers único por id, 1 pedido produce 1 fila. Con duplicado, los pedidos de ese cliente se multiplican. Después ejecuta la comprobación: Compara COUNT(*) antes/después y COUNT(DISTINCT order_id).
• Provoca deliberadamente un caso problemático relacionado con este error frecuente: Usar DISTINCT al final puede ocultar un JOIN mal diseñado y cambiar métricas.. Comprueba que sabes detectarlo y corregirlo.

Reto sin ayuda

Crea una copia de customers con un customer_id duplicado y observa cómo crece el JOIN.

Resultado esperado

Con customers único por id, 1 pedido produce 1 fila. Con duplicado, los pedidos de ese cliente se multiplican.

Cómo verificarlo

Compara COUNT(*) antes/después y COUNT(DISTINCT order_id).

Checklist de validación

• El resultado cumple: Con customers único por id, 1 pedido produce 1 fila. Con duplicado, los pedidos de ese cliente se multiplican.
• Has ejecutado esta verificación y puedes explicar el resultado: Compara COUNT(*) antes/después y COUNT(DISTINCT order_id).
• Has probado al menos un caso límite o dato inválido y el comportamiento es explícito, no silencioso.
• Puedes repetir la práctica desde cero sin copiar la solución y dejar evidencia (consulta, commit, captura o salida de consola).

Errores frecuentes

• Usar DISTINCT al final puede ocultar un JOIN mal diseñado y cambiar métricas.

Qué debes recordar

Debes poder explicar qué filas produce la consulta y por qué.

Preguntas de entrevista

• ¿Cómo demostrarías que una consulta no está duplicando métricas? Aplícalo concretamente a «JOIN y control de duplicaciones».
• ¿Qué comprobaciones harías antes de publicar este resultado a negocio? Explica qué evidencia enseñarías al revisor.

Siguiente paso

Usarás CTEs para separar lógica y facilitar pruebas.

Recursos de esta lección