Manual de campo · trampas de SQL

Trampas de SQL: consultas que corren y están mal

Quince errores de SQL que no dan error: cada uno con un dataset mínimo, la consulta rota, la corregida y por qué. Comprobados en DuckDB.

El join que multiplica filasAgregar después de un JOIN uno-a-muchos duplica cada fila del lado «uno» tantas veces como filas tenga enfrente, y toda suma posterior sale inflada.
Una tasa sin denominador no significa nadaUn conteo por sí solo premia a quien más aparece; una tasa sin un mínimo de muestra premia a quien menos aparece. Hacen falta las dos cosas.
Un WHERE sobre la tabla derecha convierte tu LEFT JOIN en INNEREl ON dice cómo se pegan las filas; el WHERE decide cuáles sobreviven. Con INNER JOIN da igual el orden; con LEFT JOIN, filtrar en el WHERE sobre una columna de la tabla de la derecha borra justo las filas sin pareja que el LEFT JOIN pretendía conservar.
El sesgo de supervivencia está en el JOINUnir un histórico contra el catálogo tal como está hoy mide quién sobrevivió, no lo que de verdad pasó: los que desaparecieron son justo los que traían la mala noticia.
Zonas horarias: guarda UTC, muestra localAgrupar por día sin decidir el huso horario reparte la misma sesión entre dos días, y el cambio de hora crea un día de 23 horas y otro de 25.
¿Por qué NOT IN devuelve cero filas?NOT IN contra una lista con un solo NULL descarta la consulta entera sin avisar. Es el peor fallo posible: no revienta, da tranquilidad.
¿Por qué COUNT(columna) da menos que COUNT(*)?COUNT(*) cuenta filas. COUNT(columna) cuenta valores no nulos de esa columna. Si la columna admite NULL, los dos números casi nunca coinciden, y la diferencia no es un error: son los nulos.
¿Por qué LIKE no encuentra un nombre que sí está en la tabla?LIKE compara carácter por carácter y distingue mayúsculas de minúsculas. Si el dato real viene en mayúsculas, en minúsculas o sin acentos, un patrón bien escrito no encuentra filas que están justo delante.
¿Por qué la transferencia más grande del mes sale como $990?Si el monto se guardó como texto, ORDER BY lo compara letra por letra: '9' va antes que '75000' porque el primer carácter de '990' es más grande, sin que importen las cifras que vienen después.
¿Por qué BETWEEN se come el último día del rango?BETWEEN 'a' AND 'b' sobre un TIMESTAMP convierte 'b' en 'b 00:00:00'. Todo lo que pasó después de la medianoche de ese día queda fuera, aunque el día entero debía contarse.
¿Por qué un self-join siempre trae una fila de más?Unir una tabla contra sí misma sin excluir la fila consigo misma hace que cada registro se empareje con su propia copia: una fila que no dice nada, pero que sí cuenta.
¿Cuándo se solapan de verdad dos intervalos de tiempo?Comparar sólo el inicio o sólo el fin no basta, y usar <= en vez de < convierte dos turnos que se tocan en un punto en un solape que no existe.
¿Por qué el saldo acumulado repite el mismo número en dos filas distintas?sum(...) OVER (ORDER BY fecha) sin especificar el marco usa RANGE por defecto: agrupa todas las filas con la misma fecha en un único bloque, y todas enseñan el mismo acumulado.
¿Por qué WHERE no puede filtrar el resultado de una window function?El WHERE se evalúa antes de que existan las columnas calculadas con OVER. Para filtrar por una window function hace falta QUALIFY, o envolver la consulta en un CTE y filtrar desde fuera.
¿Por qué el WHERE no encuentra a quien 'siempre' paga en efectivo?Filtrar en el WHERE antes de agrupar responde otra pregunta: cuenta a quien pagó en efectivo varias veces, no comprueba que pagara SIEMPRE así. 'Siempre' describe el grupo entero, y eso se comprueba en el HAVING.

¿Las reconocerías sin aviso? Una al día, en cuatro opciones.

Trampa del día →