Las tablas de TiendaVerde no tienen filas duplicadas: cada una tiene su clave primaria id, así que no hay dos iguales. Y sin embargo, en cuanto proyectas solo una parte de las columnas, empiezan a aparecer repeticiones por todas partes. Preguntar "¿en qué países tengo clientes?" sobre una tabla de quince filas devuelve quince respuestas cuando solo hay tres países distintos. En esta lección aprenderás por qué ocurre, cómo lo resuelve DISTINCT, por qué actúa sobre la combinación completa de columnas del SELECT (el malentendido más habitual del módulo), dónde encaja en el orden lógico de ejecución, y cuándo la aparición de DISTINCT en una consulta es en realidad la señal de que la consulta está mal planteada.

1. Por qué aparecen filas repetidas
2. DISTINCT sobre una columna
3. DISTINCT sobre varias columnas: el malentendido clásico
4. Dónde encaja DISTINCT en el orden lógico
5. DISTINCT combinado con WHERE y con ORDER BY
6. COUNT(DISTINCT columna): un anticipo del módulo 4
7. DISTINCT ON: la extensión de PostgreSQL
8. El coste de DISTINCT y cuándo delata un error
9. Errores Comunes y Consejos
10. Ejercicios
11. Conclusión

Empecemos por el problema:

15 filas. Una por cliente, porque SELECT devuelve una fila de resultado por cada fila de origen. La proyección ha eliminado las columnas que hacían única a cada fila (id, email, nombre...), y lo que queda se repite.

Es importante entender que esto no es un fallo de los datos. En el modelo relacional puro una relación es un conjunto y no admite duplicados, pero SQL no trabaja con conjuntos sino con multiconjuntos (bags): permite repeticiones y solo las elimina si se lo pides explícitamente. Fue una decisión pragmática de los diseñadores del lenguaje: eliminar duplicados cuesta tiempo, y en la mayoría de las consultas no hace falta.

Lo mismo con las ciudades:

Devuelve 15 filas con Valencia cuatro veces y Barcelona dos.

La palabra clave DISTINCT se escribe inmediatamente después de SELECT y elimina las filas repetidas del resultado:

3 filas. Ahora sí has respondido a la pregunta "¿en qué países tengo clientes?".

11 filas de las 15: Valencia aparecía 4 veces y Barcelona 2.

Otro caso útil: saber qué métodos de pago se usan realmente. La restricción CHECK de la tabla admite cuatro, pero ¿se usan todos?

Los cuatro. Y los estados:

Los cinco valores del dominio están representados.

Muy importante: DISTINCT no ordena. Los resultados de arriba salen en un orden que PostgreSQL elige según cómo haya eliminado los duplicados (normalmente con una tabla hash, cuyo orden es impredecible). Podrías ver Francia, España, Portugal perfectamente. Si quieres un orden concreto, ORDER BY (sección 5).

Dos detalles de sintaxis:

1. DISTINCT afecta a toda la lista de columnas, no a la que tiene al lado. SELECT DISTINCT pais, ciudad no es "el pais distinto y la ciudad": es la sección 3.
2. DISTINCT(pais) funciona, pero es engañoso: esos paréntesis son los de una expresión, no los de una función. SELECT DISTINCT (pais), ciudad sigue aplicando DISTINCT a las dos columnas. No escribas DISTINCT con paréntesis; induce a error a quien lo lea.

Y un apunte sobre nulos: para DISTINCT, todos los NULL cuentan como un mismo valor y se colapsan en una sola fila. Es una excepción deliberada a la regla de que NULL no es igual a NULL, y la verás en el ejercicio 3.

Esta es la parte que hay que interiorizar bien:

11 filas, y España aparece siete veces. ¿No habíamos dicho que DISTINCT elimina duplicados?

Los ha eliminado. Lo que ocurre es que DISTINCT compara la fila completa, no columna por columna. (España, Valencia) y (España, Madrid) son dos filas distintas, aunque compartan el primer valor. Solo se elimina una fila si todos sus valores coinciden con los de otra: (España, Valencia) aparecía cuatro veces en la tabla y ha quedado una.

Piénsalo así: DISTINCT mira la fila del resultado como si fuera una tupla y se pregunta "¿he visto ya exactamente esta tupla?".

Otro ejemplo, esta vez sobre el catálogo: ¿qué combinaciones de categoría y proveedor existen?

Con ORDER BY para poder leerlo (lo justificamos en la sección 5):

12 combinaciones a partir de 20 productos. Se lee mucha información de negocio en esa tabla: la categoría 4 (Bebidas) se surte de tres proveedores distintos, mientras que la 6 (Complementos) depende de uno solo, y ese único proveedor —el 5, EcoNordic— es precisamente el que está inactivo. Sin DISTINCT habrías tenido que leer 20 filas para llegar a la misma conclusión.

Si de verdad quieres "un país por fila y algo de sus ciudades", DISTINCT no es la herramienta: necesitas agrupar, que es GROUP BY (lección 04-05). La diferencia conceptual, para tenerla clara desde ya:

DISTINCT se aplica después de la proyección del SELECT y antes de ORDER BY. Esto es coherente: solo se pueden comparar filas duplicadas una vez que se sabe qué columnas contienen.

De ahí se deducen dos reglas que verás en acción enseguida:

7 ciudades españolas. El orden es: FROM trae las 15 filas → WHERE deja 11 → SELECT proyecta ciudad → DISTINCT reduce a 7.

Ahora el orden sí está garantizado (alfabético). ORDER BY es la lección siguiente; aquí lo usamos solo para hacer legibles los resultados.

Prueba esto:

El mensaje es explícito y la razón es lógica, no arbitraria. Después del DISTINCT solo quedan tres filas: España, Portugal y Francia. La fila España procede de once filas originales con once ciudades distintas. ¿Por cuál de las once habría que ordenarla? La pregunta no tiene respuesta, así que PostgreSQL se niega a inventarse una.

La regla, memorizable: con SELECT DISTINCT, todo lo que aparezca en ORDER BY debe aparecer también en la lista del SELECT.

Si lo que querías era ordenar los países por algún criterio derivado de las ciudades, necesitas GROUP BY y una función de agregación (módulo 4).

Un caso frecuente que también falla por esto: ordenar por una columna que no proyectas.

Mismo mensaje. Y si la "arreglas" añadiendo precio al SELECT, cambias la pregunta: pasarías de "categorías distintas" (6 filas) a "combinaciones distintas de categoría y precio" (20 filas, porque casi todos los precios son únicos). Añadir columnas al SELECT debilita el DISTINCT.

Muchas veces no quieres la lista de valores distintos, sino cuántos hay. Para eso se combina DISTINCT con la función de agregación COUNT:

Fíjate en la diferencia entre las tres variantes de COUNT:

Aquí COUNT(ciudad) coincide con COUNT(*) porque en TiendaVerde ningún cliente tiene la ciudad a nulo, pero la columna admite nulos y en otra base de datos la diferencia sería visible.

No profundizamos más: COUNT, SUM, AVG, MIN y MAX son la lección 04-04, y la agrupación por categorías, la 04-05. Lo dejamos aquí simplemente porque es la aplicación más frecuente de DISTINCT en el trabajo real de análisis.

PostgreSQL añade una variante que no está en el estándar SQL y que es enormemente útil: DISTINCT ON (columnas) conserva la primera fila de cada grupo de valores, según el orden que tú indiques.

Problema: el producto más caro de cada categoría.

Seis filas, una por categoría, con el producto más caro de cada una. Esto con DISTINCT a secas es imposible.

Cómo funciona, paso a paso:

1. ORDER BY categoria_id, precio DESC ordena todas las filas: primero agrupadas por categoría, y dentro de cada categoría, de más caro a más barato.
2. DISTINCT ON (categoria_id) recorre ese resultado ordenado y se queda con la primera fila de cada valor de categoria_id, descartando el resto.

De ahí sale la regla de oro:

Las columnas de DISTINCT ON (...) deben ser las primeras del ORDER BY, y en el mismo orden. Si no lo son, PostgreSQL da error; y si el ORDER BY no desempata bien lo que viene después, la fila elegida dentro de cada grupo es impredecible.

Si cambias precio DESC por precio, obtienes el producto más barato de cada categoría:

El patrón "la fila más X de cada grupo" (el último pedido de cada cliente, la reseña más reciente de cada producto, el precio más alto de cada categoría) es uno de los más pedidos en el mundo real, y DISTINCT ON lo resuelve en tres líneas.

Portabilidad:

La forma portable con funciones de ventana se estudia en la lección 10-03, y es la que deberás usar si tu SQL tiene que funcionar fuera de PostgreSQL. Mientras trabajes con PostgreSQL, DISTINCT ON es más corto y suele ser más rápido.

DISTINCT no es gratis. Para saber si una fila está repetida, PostgreSQL tiene que comparar todas las filas entre sí, y lo hace de una de estas dos formas:

Con 15 filas es instantáneo. Con diez millones de filas y una columna de texto largo, un DISTINCT innecesario puede convertir una consulta de 50 ms en una de 30 segundos. Podrás verlo tú mismo con EXPLAIN en el módulo 8.

Y hay algo más importante que el coste: un DISTINCT inesperado suele ser el síntoma de una consulta mal planteada, no la solución. El caso típico llega en el módulo 3:

Esa consulta devuelve 20 filas y no 12, porque Lucía Martínez tiene tres pedidos (1, 5 y 15) y aparece tres veces. El reflejo natural es añadir DISTINCT y quedarse tranquilo. Pero el DISTINCT no arregla nada: oculta el hecho de que la unión ha multiplicado las filas. Si mañana añades una columna al SELECT —por ejemplo p.fecha_pedido—, las filas vuelven a duplicarse y el DISTINCT deja de servir.

La lista de comprobación cuando te descubras escribiendo DISTINCT:

1. ¿Hay duplicados de verdad, o los está creando mi consulta? Si es lo segundo, el problema está en la unión, no en la proyección.
2. ¿Lo que quiero es "valores distintos" o "un resultado por grupo"? Si es lo segundo, es GROUP BY (04-05) o DISTINCT ON (sección 7).
3. ¿Quiero comprobar existencia? Entonces la herramienta correcta es EXISTS (lección 07-03), que no multiplica filas y por tanto no necesita deduplicar.
4. ¿Estoy deduplicando por columnas que no necesito? Quitar del SELECT una columna innecesaria puede hacer que el DISTINCT sobre.

DISTINCT es perfectamente legítimo para lo que hemos hecho en esta lección: preguntar "¿qué valores distintos hay en esta columna?". Lo sospechoso es usarlo como parche.

• Creer que DISTINCT columna1, columna2 deduplica solo por la primera. Deduplica por la combinación completa. Es el malentendido número uno.
• Escribir DISTINCT(columna). Funciona, pero hace pensar que DISTINCT es una función que se aplica a esa columna. No lo es. Escribe DISTINCT columna1, columna2.
• Esperar que DISTINCT ordene. No ordena. Si necesitas orden, ORDER BY.
• Ordenar por una columna que no está en un SELECT DISTINCT. ORDER BY expressions must appear in select list. Y "arreglarlo" añadiendo la columna cambia la pregunta.
• Añadir columnas y no darse cuenta de que el DISTINCT deja de servir. Cada columna nueva puede multiplicar las filas del resultado.
• Usar DISTINCT para tapar duplicados creados por un JOIN. Corrige la consulta, no el síntoma.
• Olvidar que los NULL se agrupan. DISTINCT devuelve una sola fila con NULL, aunque haya cien.
• Usar DISTINCT ON sin el ORDER BY correcto. La fila que se conserva de cada grupo es entonces impredecible: hoy una, mañana otra.
• Consejo: para contar valores únicos, COUNT(DISTINCT col) en lugar de traerte la lista y contarla a mano.
• Consejo: usa DISTINCT como herramienta de exploración. SELECT DISTINCT estado FROM pedidos; es la forma más rápida de saber qué valores contiene realmente una columna, incluidos los que no deberían estar ahí.
• Consejo: si DISTINCT es lento, mira el plan. EXPLAIN (módulo 8) te dirá si está ordenando en disco.

Marketing quiere saber desde qué ciudades se ha comprado en Portugal y Francia. Escribe una consulta que devuelva las combinaciones distintas de pais y ciudad de los clientes que no sean de España, ordenadas por país y ciudad. Explica por qué el resultado tiene el número de filas que tiene.

Un compañero escribe esta consulta para saber cuántos métodos de pago distintos se usan y se sorprende del resultado:

Explica qué devuelve realmente, cuántas filas y por qué no responde a su pregunta. Escribe después las dos consultas correctas: la que da la lista de métodos y la que da el número.

Usando DISTINCT ON, obtén el pedido más reciente de cada cliente que haya comprado: cliente_id, id del pedido, fecha_pedido y estado. Explica por qué el resultado tiene 12 filas y no 15, y qué papel juega el ORDER BY.

Solución 1

4 filas. El razonamiento sigue el orden lógico de ejecución:

1. FROM clientes → 15 filas.
2. WHERE pais <> 'España' → quedan 4 (los clientes 7, 8, 9 y 10). Aquí no hay problema de nulos porque pais es NOT NULL; si admitiera nulos, esos clientes se habrían perdido silenciosamente, como viste en 02-03.
3. SELECT pais, ciudad → proyecta dos columnas de esas 4 filas.
4. DISTINCT → busca combinaciones repetidas... y no hay ninguna, porque los cuatro clientes extranjeros viven en cuatro ciudades diferentes.

Es decir, en este caso concreto DISTINCT no elimina nada. Eso no lo hace inútil: garantiza que si mañana se registra un segundo cliente en Lisboa, el informe seguirá siendo correcto.

Solución 2

La consulta del compañero devuelve las combinaciones distintas de método de pago y estado:

10 filas. tarjeta aparece cuatro veces, una por cada estado en el que hay algún pedido pagado con tarjeta. No responde a "cuántos métodos de pago distintos hay" porque DISTINCT deduplica la pareja completa, y las parejas son distintas aunque compartan el método.

Las dos consultas correctas:

La moraleja: cada columna que añades al SELECT puede multiplicar las filas del resultado, porque debilita la condición de igualdad que usa DISTINCT. Antes de añadir una columna a un SELECT DISTINCT, pregúntate si sigue respondiendo a tu pregunta.

Solución 3

12 filas y no 15. El motivo está en los huecos deliberados del conjunto de datos: los clientes 13, 14 y 15 no han hecho ningún pedido, así que no aparecen en la tabla pedidos y no hay nada que agrupar para ellos. Una consulta sobre pedidos solo puede hablar de clientes que han pedido; para listar también a los que nunca compraron hace falta combinar las dos tablas con un LEFT JOIN, que es exactamente el contenido de la lección 03-03.

El papel del ORDER BY es doble y ambos son imprescindibles:

• cliente_id primero porque es la columna del DISTINCT ON: PostgreSQL exige que coincidan, ya que necesita las filas de cada cliente juntas para quedarse con una.
• fecha_pedido DESC después porque determina cuál de las filas de cada cliente sobrevive: la primera del grupo, es decir, la de fecha más alta.

Si escribieras ORDER BY cliente_id, fecha_pedido (ascendente), obtendrías el primer pedido de cada cliente. Y si omitieras la segunda columna del ORDER BY, la fila elegida dentro de cada cliente sería la que el motor devolviera primero, que puede cambiar entre ejecuciones.

Comprobación rápida: Lucía Martínez (cliente 1) tiene los pedidos 1, 5 y 15, con fechas 2025-03-04, 2025-05-07 y 2025-12-02. Ha salido el 15, el más reciente. Correcto.

Ya sabes tratar los duplicados:

• Las filas repetidas no vienen de los datos, sino de la proyección: al quitar columnas, lo que queda se repite. SQL trabaja con multiconjuntos y no las elimina si no se lo pides.
• DISTINCT se escribe justo después de SELECT y elimina filas repetidas comparando la combinación completa de columnas proyectadas, no solo la primera.
• Se aplica después de la proyección y antes de ORDER BY, de donde sale la restricción de que todo lo que ordenes debe estar en el SELECT.
• Los NULL se colapsan en una sola fila, por excepción a la regla general de los nulos.
• COUNT(DISTINCT columna) cuenta valores únicos y es la aplicación más habitual en análisis de datos; las agregaciones completas llegan en el módulo 4.
• DISTINCT ON (...) es una extensión de PostgreSQL que devuelve la primera fila de cada grupo según el ORDER BY, y resuelve en tres líneas el patrón "la fila más reciente / más cara de cada X". Fuera de PostgreSQL se hace con funciones de ventana (módulo 10).
• DISTINCT cuesta (ordenar o construir una tabla hash) y, cuando aparece por sorpresa, suele delatar una consulta mal planteada más que resolver un problema.

En la siguiente lección, Ordenando datos con ORDER BY, dejarás de aceptar el orden que el motor tenga a bien darte. Verás cómo ordenar por una o varias columnas, cómo se resuelven los empates, cómo ordenar por alias y por expresiones calculadas, dónde coloca PostgreSQL los valores nulos (y por qué MySQL los pone en el otro extremo) y por qué la letra Ñ puede aparecer donde no esperas.