# Módulo 2: SQL para leer ## 1. Objetivo Que puedas traer exactamente las filas que necesitás, ordenadas y acotadas. Al terminar vas a manejar `SELECT`, `WHERE`, `ORDER BY`, `LIMIT`, los operadores de comparación, `LIKE`, `IN`, `BETWEEN`, y vas a entender por qué `= NULL` no funciona **nunca**. ## 2. La analogía: el pedido en la verdulería Cuando pedís en la verdulería no decís "traeme todo y yo elijo". Decís: *dame* (qué) *tres kilos de manzanas* (cuánto) *de las rojas* (cuáles) *empezando por las más maduras* (en qué orden). SQL es igual, y las palabras aparecen siempre en el mismo lugar: ```sql SELECT columnas -- qué quiero ver FROM tabla -- de dónde WHERE condicion -- qué filas ORDER BY columna -- en qué orden LIMIT n; -- cuántas ``` Ese orden es obligatorio para escribirla. Pero la base la **ejecuta** en otro orden, y saberlo evita confusiones: primero `FROM` (de dónde saco filas), después `WHERE` (cuáles me quedo), después `SELECT` (qué columnas muestro), después `ORDER BY` y por último `LIMIT`. Volvemos sobre esto en el módulo 5, cuando el orden explique un error concreto. ## 3. Los datos con los que vamos a jugar Copiá esto tal cual en `psql`: lo usamos el resto del módulo. ```sql CREATE TABLE productos ( id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, nombre VARCHAR(100) NOT NULL, precio NUMERIC(10,2) NOT NULL, stock INTEGER NOT NULL DEFAULT 0, categoria VARCHAR(50), activo BOOLEAN NOT NULL DEFAULT true ); INSERT INTO productos (nombre, precio, stock, categoria) VALUES ('Yerba 1kg', 3200.00, 40, 'almacen'), ('Cafe molido', 5400.50, 12, 'almacen'), ('Cuaderno A4', 1800.00, 0, 'libreria'), ('Lapicera azul', 350.00, 200, 'libreria'), ('Alfajor', 600.00, 85, 'kiosco'), ('Chicle', 150.00, 300, NULL); ``` Fijate que el chicle quedó **sin categoría**. Va a ser el protagonista del punto 8. ## 4. SELECT: qué columnas ```sql SELECT * FROM productos; SELECT nombre, precio FROM productos; ``` El `*` significa "todas las columnas". Sirve para explorar en la consola y **no debería aparecer en el código de tu aplicación**, por tres razones concretas: traés bytes que no usás, tu código se rompe silenciosamente si alguien reordena columnas, y exponés columnas que quizás no querías mostrar (un hash de contraseña, por ejemplo). Podés calcular al vuelo y ponerle nombre al resultado con `AS`: ```sql SELECT nombre, precio, precio * 1.21 AS precio_con_iva FROM productos; ``` ```text nombre | precio | precio_con_iva ---------------+---------+---------------- Yerba 1kg | 3200.00 | 3872.0000 Cafe molido | 5400.50 | 6534.6050 ``` ## 5. WHERE: qué filas ```sql SELECT nombre, precio FROM productos WHERE precio < 1000; SELECT * FROM productos WHERE categoria = 'libreria'; SELECT * FROM productos WHERE stock = 0; SELECT * FROM productos WHERE activo; ``` Los operadores de comparación: | Operador | Significa | |---|---| | `=` | Igual. **Un solo signo igual**, no `==` | | `<>` o `!=` | Distinto | | `<` `>` `<=` `>=` | Menor, mayor, menor o igual, mayor o igual | | `AND` `OR` `NOT` | Combinaciones lógicas | En SQL la igualdad es `=`. Si venís de JavaScript vas a escribir `==` durante dos semanas; el error dice algo como `operator does not exist`. Y con `AND` / `OR` mezclados, **usá paréntesis siempre**, aunque creas que no hacen falta: ❌ Ambiguo a la vista, y probablemente no es lo que querías: ```sql SELECT * FROM productos WHERE categoria = 'almacen' OR categoria = 'kiosco' AND stock > 50; ``` ✅ Explícito: ```sql SELECT * FROM productos WHERE (categoria = 'almacen' OR categoria = 'kiosco') AND stock > 50; ``` `AND` tiene más precedencia que `OR`, igual que `*` sobre `+`. La primera consulta trae todo `almacen` (sin importar el stock) más los kiosco con stock alto. Casi nunca es la intención. ## 6. IN y BETWEEN: los atajos que se leen mejor ```sql -- Estas dos hacen lo mismo: SELECT * FROM productos WHERE categoria = 'almacen' OR categoria = 'kiosco'; SELECT * FROM productos WHERE categoria IN ('almacen', 'kiosco'); -- Y estas dos también: SELECT * FROM productos WHERE precio >= 500 AND precio <= 3200; SELECT * FROM productos WHERE precio BETWEEN 500 AND 3200; ``` `IN` es "pertenece a esta lista". `BETWEEN` es un rango **inclusivo en los dos extremos**: `BETWEEN 500 AND 3200` incluye el 500 y el 3200. Ese detalle importa con fechas y es una fuente clásica de bugs. `fecha BETWEEN '2026-03-01' AND '2026-03-31'` sobre una columna `TIMESTAMPTZ` deja afuera casi todo el 31, porque `'2026-03-31'` significa `'2026-03-31 00:00:00'`. Para rangos de fechas, la forma segura es: ```sql SELECT * FROM pedidos WHERE creado_en >= '2026-03-01' AND creado_en < '2026-04-01'; ``` Mayor o igual al principio, **estrictamente menor** al día siguiente. Sin excepciones, sin importar la hora. Los dos tienen su negación: `NOT IN`, `NOT BETWEEN`. ## 7. LIKE: buscar por texto ```sql SELECT * FROM productos WHERE nombre LIKE 'Cua%'; -- empieza con "Cua" SELECT * FROM productos WHERE nombre LIKE '%azul'; -- termina con "azul" SELECT * FROM productos WHERE nombre LIKE '%fal%'; -- contiene "fal" SELECT * FROM productos WHERE nombre LIKE 'C_fe%'; -- una letra cualquiera en el _ ``` Dos comodines y nada más: `%` es "cualquier cantidad de caracteres, incluso ninguno", `_` es "exactamente un caracter". `LIKE` distingue mayúsculas de minúsculas. Como el usuario que escribe en un buscador no las respeta, en PostgreSQL tenés `ILIKE`, que las ignora: ```sql SELECT * FROM productos WHERE nombre ILIKE '%CAFE%'; ``` ⚠ Guardá esto para el módulo 7: un `LIKE '%algo%'` que empieza con `%` **no puede usar un índice común**. Con pocos datos ni lo notás; con muchos, es la consulta que hace lenta tu aplicación. Para búsqueda de texto en serio existe la búsqueda *full-text*, que queda fuera de este curso pero conviene que sepas que existe. ## 8. NULL: el que no es igual a nada Acá viene lo que más confunde de SQL, y es mejor entenderlo hoy que descubrirlo en producción. `NULL` **no es** cero, ni cadena vacía, ni `false`. `NULL` significa **"no se sabe"**. Y de ahí sale todo: si no sé cuánto vale A, y no sé cuánto vale B, ¿A es igual a B? No puedo afirmarlo. Entonces `NULL = NULL` no da `true` ni da `false`: da... `NULL`. SQL tiene tres valores lógicos: verdadero, falso y desconocido. Probalo: ```sql SELECT * FROM productos WHERE categoria = NULL; ``` ```text id | nombre | precio | stock | categoria | activo ----+--------+--------+-------+-----------+-------- (0 rows) ``` Cero filas. Y el chicle tiene la categoría en `NULL`. No falló, no avisó: te devolvió la nada. La forma correcta usa un operador aparte: ❌ Nunca: ```sql SELECT * FROM productos WHERE categoria = NULL; SELECT * FROM productos WHERE categoria <> NULL; ``` ✅ Siempre: ```sql SELECT * FROM productos WHERE categoria IS NULL; SELECT * FROM productos WHERE categoria IS NOT NULL; ``` Hay una segunda trampa, más silenciosa. Esta consulta: ```sql SELECT * FROM productos WHERE categoria <> 'kiosco'; ``` **no** trae el chicle. Pedimos "categoría distinta de kiosco" y el chicle no tiene categoría, así que la base no puede afirmar que sea distinta. Si querés incluirlo, tenés que decirlo: ```sql SELECT * FROM productos WHERE categoria <> 'kiosco' OR categoria IS NULL; -- o, más corto en PostgreSQL: SELECT * FROM productos WHERE categoria IS DISTINCT FROM 'kiosco'; ``` Y `COALESCE` te da un valor de reemplazo cuando algo es nulo: ```sql SELECT nombre, COALESCE(categoria, 'sin categoria') AS categoria FROM productos; ``` > Cada vez que escribas un `WHERE` sobre una columna que **acepta** nulos, preguntate qué querés que pase con las filas nulas. La base no lo va a adivinar por vos, y su default probablemente no sea el tuyo. ## 9. ORDER BY y LIMIT ```sql SELECT nombre, precio FROM productos ORDER BY precio DESC; SELECT nombre, precio FROM productos ORDER BY categoria ASC, precio DESC; SELECT nombre, precio FROM productos ORDER BY precio DESC LIMIT 3; SELECT nombre, precio FROM productos ORDER BY precio DESC LIMIT 3 OFFSET 3; ``` `ASC` (ascendente) es el default; `DESC` invierte. Podés ordenar por varias columnas: la segunda desempata a la primera. `LIMIT` corta la cantidad de filas y `OFFSET` saltea las primeras. Juntos son la **paginación**: página 1 es `LIMIT 20 OFFSET 0`, página 2 es `LIMIT 20 OFFSET 20`. Es exactamente lo que hay detrás de `GET /productos?pagina=2&limite=20` en tu API. Y una regla que parece obsesiva hasta que te muerde: **paginar sin `ORDER BY` es un bug**. Sin orden explícito, la base puede devolverte las filas en cualquier orden, y no tiene por qué ser el mismo entre dos consultas. Resultado: la misma fila aparece en la página 1 y en la 2, y otra no aparece nunca. Si dos filas empatan en la columna de orden, agregá el `id` como desempate final: ```sql SELECT * FROM productos ORDER BY precio DESC, id ASC LIMIT 20 OFFSET 20; ``` ## 10. Ejercicio Sobre la tabla `productos` del punto 3: 1. Traé nombre y precio de los productos con stock mayor a 50, del más caro al más barato. 2. Traé los productos de `almacen` o `libreria` usando `IN`. 3. Traé los productos con precio entre 300 y 1000, ambos incluidos. 4. Traé los productos cuyo nombre contenga "a", sin importar mayúsculas. 5. Traé los productos **sin categoría**. Después escribí la versión con `= NULL` y confirmá con tus ojos que devuelve cero filas. 6. Traé los productos cuya categoría **no sea** `almacen`, incluyendo los que no tienen categoría. 7. Los 2 productos más caros, y después los 2 siguientes usando `OFFSET`. 8. Mostrá el nombre y una columna `estado` que diga el stock, poniendo `'sin stock'` cuando sea 0. Pista: `NULLIF` y `COALESCE`, o buscá `CASE`. 9. Una sola consulta: productos activos, de `kiosco` o sin categoría, con precio menor a 1000, ordenados por precio. Prestá atención a los paréntesis. ## 11. Autoevaluación Diez preguntas: varias te piden contar las filas que devuelve una consulta sobre la tabla `productos` del punto 3, que se repite en cada una. Contá a mano, sin ejecutar y sin volver a mirar arriba. ```quiz titulo: Autoevaluación — Módulo 2 modo: practica preguntas: - tipo: opcion-multiple enunciado: ¿Cuántas filas devuelve esta consulta? lenguaje: sql codigo: | -- productos -- nombre | precio | stock | categoria -- Yerba 1kg | 3200.00 | 40 | almacen -- Cafe molido | 5400.50 | 12 | almacen -- Cuaderno A4 | 1800.00 | 0 | libreria -- Lapicera azul | 350.00 | 200 | libreria -- Alfajor | 600.00 | 85 | kiosco -- Chicle | 150.00 | 300 | NULL SELECT nombre FROM productos WHERE categoria = 'almacen' OR categoria = 'kiosco' AND stock > 50; opciones: ["3", "1", "2", "0"] correcta: "3" explicacion: >- `AND` se evalúa antes que `OR`, así que se lee `almacen OR (kiosco AND stock > 50)`: las dos de almacén, sin mirar el stock, más el Alfajor. El 1 es la trampa de leerla como si tuviera paréntesis alrededor del `OR`; con `(... OR ...) AND stock > 50` sí daría solo el Alfajor. - tipo: opcion-multiple enunciado: ¿Cuántas filas devuelve esta consulta? lenguaje: sql codigo: | -- misma tabla: el Chicle es el único con categoria NULL SELECT * FROM productos WHERE categoria = NULL; opciones: - "0" - "1" - "6" - Da error de sintaxis correcta: "0" explicacion: >- `NULL` significa "no se sabe", y comparar algo con `=` contra lo desconocido no da verdadero sino `NULL`, así que ninguna fila pasa el filtro. No es un error de sintaxis: la base te devuelve la nada sin avisar. Para traer el Chicle va `IS NULL`. - tipo: opcion-multiple enunciado: ¿Cuántas filas devuelve esta consulta? lenguaje: sql codigo: | -- productos -- nombre | categoria -- Yerba 1kg | almacen -- Cafe molido | almacen -- Cuaderno A4 | libreria -- Lapicera azul | libreria -- Alfajor | kiosco -- Chicle | NULL SELECT nombre FROM productos WHERE categoria <> 'kiosco'; opciones: ["4", "5", "6", "1"] correcta: "4" explicacion: >- Queda afuera el Alfajor, que es kiosco, y **también el Chicle**: su categoría es desconocida, así que la base no puede afirmar que sea distinta de kiosco. El 5 es la trampa de contarlo. Para incluirlo, `OR categoria IS NULL` o `IS DISTINCT FROM 'kiosco'`. - tipo: opcion-multiple enunciado: ¿Cuántas filas devuelve esta consulta? lenguaje: sql codigo: | -- productos -- nombre | precio -- Yerba 1kg | 3200.00 -- Cafe molido | 5400.50 -- Cuaderno A4 | 1800.00 -- Lapicera azul | 350.00 -- Alfajor | 600.00 -- Chicle | 150.00 SELECT nombre FROM productos WHERE precio BETWEEN 600 AND 3200; opciones: ["3", "1", "2", "4"] correcta: "3" explicacion: >- `BETWEEN` es **inclusivo en los dos extremos**: entran el Alfajor (600), el Cuaderno (1800) y la Yerba (3200). El 1 sale de creer que los extremos quedan afuera, y el 2 de incluir solo uno. - tipo: opcion-multiple enunciado: >- La columna `creado_en` es `TIMESTAMPTZ`. Querés todos los pedidos de marzo de 2026, sin perder ninguno. ¿Qué condición usás? opciones: - "`creado_en >= '2026-03-01' AND creado_en < '2026-04-01'`" - "`creado_en BETWEEN '2026-03-01' AND '2026-03-31'`" - "`creado_en > '2026-03-01' AND creado_en <= '2026-03-31'`" - "`creado_en LIKE '2026-03%'`" correcta: "`creado_en >= '2026-03-01' AND creado_en < '2026-04-01'`" explicacion: >- `'2026-03-31'` es el 31 a las 00:00, así que el `BETWEEN` deja afuera casi todo ese día; la versión con `>` y `<=` pierde eso y, encima, lo que pasó justo a las 00:00 del 1. Mayor o igual al principio y **estrictamente menor** al día siguiente funciona sin importar la hora. `LIKE` es para texto, no para fechas. - tipo: emparejar enunciado: Uní cada patrón de `LIKE` con lo que busca. pares: - ["`nombre LIKE 'Cua%'`", "Empieza con Cua"] - ["`nombre LIKE '%azul'`", "Termina con azul"] - ["`nombre LIKE '%fal%'`", "Contiene fal en cualquier posición"] - ["`nombre LIKE 'C_fe%'`", "Una C, exactamente un caracter cualquiera, fe y después lo que sea"] distractores: - Contiene fal, sin distinguir mayúsculas explicacion: >- `%` es cualquier cantidad de caracteres, incluso ninguno, y `_` es exactamente uno. `LIKE` distingue mayúsculas en PostgreSQL; para ignorarlas está `ILIKE`, así que el distractor no corresponde a ningún patrón. - tipo: ordenar enunciado: >- Una consulta se escribe `SELECT ... FROM ... WHERE ... ORDER BY ... LIMIT`, pero la base la **ejecuta** en otro orden. Ordená cómo la ejecuta. pasos: - "`FROM`: de qué tabla saca las filas" - "`WHERE`: con qué filas se queda" - "`SELECT`: qué columnas muestra" - "`ORDER BY`: en qué orden las pone" - "`LIMIT`: cuántas devuelve" explicacion: >- Primero hay que tener filas (`FROM`) para poder descartarlas (`WHERE`); recién después se eligen las columnas, se ordena y se corta. Por eso `LIMIT` sin `ORDER BY` corta un orden que nadie eligió. - tipo: opcion-multiple enunciado: >- Tu endpoint `GET /productos?pagina=2` usa `LIMIT 20 OFFSET 20` sin `ORDER BY`. Un usuario ve el mismo producto en la página 1 y en la 2, y otro no le aparece nunca. ¿Cuál es el arreglo? opciones: - Agregar un `ORDER BY` por la columna que corresponda, con el `id` como desempate final - Cambiar `OFFSET 20` por `OFFSET 21` - Agregar `DISTINCT` para que no se repitan - Bajar el `LIMIT` a 10 correcta: Agregar un `ORDER BY` por la columna que corresponda, con el `id` como desempate final explicacion: >- Sin orden explícito la base puede devolver las filas en cualquier orden, y no tiene por qué ser el mismo entre dos consultas. `DISTINCT` no sirve porque cada página es una consulta aparte; y el `id` al final desempata las filas con el mismo valor en la columna de orden. - tipo: respuesta-multiple enunciado: >- En `productos`, el Chicle es el único con `categoria` en `NULL`. ¿Cuáles de estas condiciones **traen el Chicle**? opciones: - "`WHERE categoria IS NULL`" - "`WHERE categoria <> 'kiosco' OR categoria IS NULL`" - "`WHERE categoria IS DISTINCT FROM 'kiosco'`" - "`WHERE categoria = NULL`" - "`WHERE categoria <> 'kiosco'`" - "`WHERE categoria NOT IN ('almacen', 'libreria', 'kiosco')`" correctas: - "`WHERE categoria IS NULL`" - "`WHERE categoria <> 'kiosco' OR categoria IS NULL`" - "`WHERE categoria IS DISTINCT FROM 'kiosco'`" explicacion: >- Solo lo traen las condiciones que dicen algo explícito sobre el nulo. `= NULL` y `<> 'kiosco'` dan desconocido para el Chicle, y `NOT IN` también: la base no puede afirmar que un valor desconocido no esté en la lista, así que lo descarta igual. - tipo: opcion-multiple enunciado: >- El buscador de tu app en PostgreSQL recibe `CAFE` y consulta `WHERE nombre LIKE '%CAFE%'`. No encuentra "Cafe molido". ¿Qué cambiás? opciones: - "`LIKE` por `ILIKE`, que ignora mayúsculas y minúsculas" - Los `%` por `_` - "`LIKE` por `=`" - Agregás un índice sobre `nombre` correcta: "`LIKE` por `ILIKE`, que ignora mayúsculas y minúsculas" explicacion: >- En PostgreSQL `LIKE` distingue mayúsculas: `CAFE` no coincide con `Cafe`. `ILIKE` las ignora. Un índice cambia la velocidad, nunca el resultado; y `_` es exactamente un caracter, así que la búsqueda empeora. ``` ## 12. Checklist + errores comunes - [ ] Escribo `SELECT ... FROM ... WHERE ... ORDER BY ... LIMIT` en el orden correcto sin pensarlo. - [ ] Uso `=` y no `==`. - [ ] Sé por qué `= NULL` devuelve cero filas siempre. - [ ] Sé que `<> 'x'` deja afuera los nulos. - [ ] Nunca pagino sin `ORDER BY`. - [ ] Sé que `BETWEEN` incluye los dos extremos y por qué eso rompe los rangos de fechas. | Error | Qué pasa | |---|---| | `WHERE campo = NULL` | Cero filas, sin ningún aviso | | Olvidar que `<>` excluye nulos | Faltan filas en el reporte y nadie sabe por qué | | `BETWEEN fecha1 AND fecha2` con timestamps | Se pierde casi todo el último día | | `LIMIT` sin `ORDER BY` | Filas repetidas o salteadas entre páginas | | `AND` y `OR` sin paréntesis | La consulta trae algo distinto de lo que leés | | `SELECT *` en el código de la app | Bytes de más y roturas silenciosas al cambiar el esquema | | `LIKE '%texto%'` en tablas grandes | No usa índice: recorre todo | Ya sabés preguntar. En el próximo módulo aprendés a **cambiar** los datos, que es más peligroso: ahí vive el `UPDATE` sin `WHERE`, el error que todos cometen una vez y nadie olvida.

Bases de Datos

Contenido del curso: