Las siete tablas de BiblioRed existen y están vacías. Esta lección las llena y enseña a interrogarlas. Es la lección más práctica del módulo: aquí aprendes las cuatro operaciones que cubren el 90 % del trabajo diario con una base de datos —insertar, consultar, modificar y borrar—, conocidas colectivamente como CRUD (Create, Read, Update, Delete).

Nos limitamos deliberadamente a una sola tabla por consulta. Recomponer información repartida entre varias tablas es un tema con suficiente sustancia para su propia lección (02-04), y agrupar y resumir, para la siguiente (02-05). Aquí construimos los cimientos: sin dominar WHERE y ORDER BY sobre una tabla, ningún JOIN saldrá bien.

El entregable de la lección es el juego de datos de prueba de BiblioRed: cuatro sucursales, ocho autores, diez socios, nueve libros, quince ejemplares, doce préstamos y cinco reservas. Todos ficticios y todos coherentes entre sí. Los usaremos hasta el final del curso, así que ejecútalos con atención y guárdalos en un fichero.

1. INSERT: dar de alta filas
2. Entregable: el juego de datos de BiblioRed
3. Reajustar los generadores de identificadores
4. SELECT: proyección, alias y DISTINCT
5. WHERE: filtrar filas
6. ORDER BY: ordenar el resultado
7. LIMIT y OFFSET: paginación
8. UPDATE: modificar filas existentes
9. DELETE: eliminar filas
10. TRUNCATE: vaciar una tabla entera
11. Errores comunes y consejos
12. Ejercicios
13. Conclusión

Empecemos por las sucursales de BiblioRed. La red opera en la ciudad ficticia de Vallmar y tiene cuatro bibliotecas.

La salida de PostgreSQL se lee así: INSERT <oid> <número de filas insertadas>. El primer número es un vestigio histórico y siempre vale 0; el segundo es el que importa.

Fíjate en tres cosas:

• No hemos dado sucursal_id. La columna es GENERATED BY DEFAULT AS IDENTITY, así que PostgreSQL le asigna el 1.
• La fecha va entre comillas simples, en formato ISO AAAA-MM-DD. El gestor la convierte a DATE porque la columna es de ese tipo.
• El teléfono va entre comillas, aunque parezca un número: es VARCHAR, como decidimos en la lección anterior.

SQL permite omitir la lista de columnas si das un valor para todas, en el orden exacto de la definición de la tabla:

¿Por qué evitarlo? Porque el día que alguien añada una columna con ALTER TABLE, o reordene la definición, todos los INSERT sin lista de columnas se romperán o, peor, insertarán valores en la columna equivocada sin dar error. Escribe siempre la lista de columnas. Es la primera regla de higiene del SQL profesional.

Hagámoslo bien:

Esta es la sucursal Norte, que a partir de ahora tendrá sucursal_id = 2.

Se pueden encadenar varias tuplas de valores separadas por comas. Es más rápido (una sola operación en lugar de N) y más legible:

La sucursal Este todavía no tiene teléfono propio: escribimos NULL sin comillas. Si escribiéramos 'NULL' estaríamos guardando la cadena de cuatro letras N-U-L-L, que no es lo mismo en absoluto.

Otra opción es omitir la columna en la lista: lo que no se menciona queda a NULL (o a su valor por defecto, si lo tuviera).

Cuando dejas que el gestor genere la clave, surge un problema práctico inmediato: ¿qué número le ha tocado? Lo necesitarás para insertar las filas hijas. PostgreSQL lo resuelve con RETURNING:

RETURNING funciona igual con UPDATE y DELETE, y puede devolver cualquier expresión, incluido *. Es una extensión de PostgreSQL muy cómoda que evita el clásico "inserto y luego consulto".

SQLite no tiene RETURNING hasta la versión 3.35 (2021); en versiones anteriores se usa la función last_insert_rowid():

Antes de aceptar la fila, el gestor verifica las tres reglas de integridad de la lección 02-01:

Esto es exactamente lo que la hoja de cálculo de BiblioRed no hacía. Aquí el error no es una molestia: es el sistema haciendo su trabajo.

Este es el script de carga. Ejecútalo entero y en este orden (las hijas necesitan a las padres) y guárdalo como datos_biblioredb.sql.

Un matiz sobre los identificadores que verás:

• En sucursales, autores, ejemplares, prestamos y reservas dejamos que el gestor los genere.
• En socios y libros los imponemos: BiblioRed está migrando desde la hoja de cálculo y quiere conservar los números de carné (Marta Alsina es la socia 14 desde 2021) y las signaturas del catálogo antiguo (331 es "El mapa del tiempo"). Es un caso realísimo, y en el apartado 3 veremos el efecto secundario que provoca.

(COUNT y UNION ALL son de las lecciones 02-05 y 02-04; aquí solo lo usamos como recuento de control.)

Y la correspondencia entre códigos e identificadores de ejemplar, que necesitarás para entender los préstamos:

Si tus recuentos coinciden, tienes el mismo juego de datos que el resto del curso.

Tres cambios en el script:

• TRUE/FALSE en socios.activo → 1/0.
• Las líneas ALTER TABLE ... RESTART WITH del paso 0 no existen en SQLite: elimínalas. Con INTEGER PRIMARY KEY sin AUTOINCREMENT, el siguiente identificador se calcula solo a partir del máximo existente.
• Las fechas se escriben igual ('2026-03-02'), pero se guardan como texto. Mientras uses el formato ISO, las comparaciones y ordenaciones seguirán funcionando, porque el orden alfabético de AAAA-MM-DD coincide con el cronológico. Es exactamente la razón por la que ese formato es el bueno.

Aquí llega el efecto secundario prometido. En socios y libros insertamos identificadores explícitos, pero el generador de la columna no se ha enterado: sigue apuntando al 1. Comprobémoslo dando de alta un socio sin indicar su identificador:

El nuevo socio ha recibido el 1, cuando los carnés de BiblioRed empiezan en el 11. Nada ha fallado, pero el desajuste ya está sembrado: los diez siguientes de alta se llevarían el 2, el 3… y el undécimo chocaría:

Es uno de los errores más desconcertantes para quien empieza, porque aparece semanas después de la carga y sin relación aparente con ella. La causa siempre es la misma: se han insertado claves a mano sin resincronizar el generador. Borremos el socio de prueba y arreglémoslo:

La solución en PostgreSQL:

O, de forma automática y sin tener que mirar el máximo a ojo:

En SQLite el problema no existe si la clave se declaró como INTEGER PRIMARY KEY sin AUTOINCREMENT: el siguiente valor se calcula como el máximo actual más uno, así que se ajusta solo.

SELECT es la instrucción más usada de SQL y la que más lecciones ocupa en este curso. Su forma mínima:

Esto es la proyección π del álgebra relacional. Recuerda que el orden en que aparecen las filas no está garantizado sin ORDER BY: aquí salen en orden de inserción porque la tabla es pequeña y recién cargada, pero no cuentes con ello.

* significa "todas las columnas". Está perfecto para explorar en la consola, pero no lo uses en código de aplicación: traes datos que no necesitas por la red, y si mañana alguien añade una columna, tu programa recibe algo que no esperaba. En un script guardado, columnas explícitas.

Observa que el NULL del teléfono de Este aparece como celda vacía en psql. Puedes hacerlo visible:

Un alias renombra una columna en el resultado, sin tocar la tabla. Es el operador de renombrado ρ del álgebra relacional.

Puntos a retener:

• AS es opcional (codigo etiqueta funciona igual), pero escribirlo hace el SQL mucho más legible.
• Para que un alias lleve espacios, mayúsculas o tildes hay que ponerlo entre comillas dobles: es un identificador. Aquí sí es aceptable, porque el alias solo vive en la salida.

También se pueden calcular columnas nuevas:

|| es el operador estándar de concatenación (funciona en PostgreSQL y SQLite; MySQL usa CONCAT()).

Cuidado con NULL en las concatenaciones: 'Pau' || NULL da NULL, no 'Pau'. Si apellidos pudiera ser nulo, el nombre completo desaparecería entero. En 02-05 veremos COALESCE, que resuelve exactamente esto.

Devuelve 15 filas con muchas repeticiones. Con DISTINCT:

DISTINCT se aplica a la combinación completa de columnas seleccionadas, no a la primera:

Son las ocho combinaciones distintas que existen, de las 15 filas originales.

Recuerda de la lección 02-01: en el álgebra relacional la proyección siempre elimina duplicados; en SQL hay que pedirlo. DISTINCT obliga al gestor a ordenar o construir una tabla de dispersión, así que tiene coste: no lo pongas "por si acaso".

WHERE es la selección σ del álgebra: se queda con las filas cuya condición sea VERDADERO (recuerda: DESCONOCIDO no pasa).

Las comparaciones funcionan también sobre texto (orden alfabético según la configuración regional) y sobre fechas:

AND tiene más precedencia que OR, igual que la multiplicación sobre la suma. Esto provoca errores silenciosos:

Devuelve 7 filas: los seis de la sucursal 1 más EJ-3081. Con paréntesis:

Consejo: usa paréntesis siempre que mezcles AND y OR, aunque sepas la precedencia. Quien lea tu consulta dentro de un año lo agradecerá.

BETWEEN a AND b es azúcar sintáctico de >= a AND <= b: ambos extremos están incluidos. Es la fuente de un error clásico con fechas y horas: BETWEEN '2026-03-01' AND '2026-03-31' sobre una columna TIMESTAMP deja fuera todo lo ocurrido el día 31 después de medianoche, porque 2026-03-31 09:00 es mayor que 2026-03-31 00:00. Con columnas DATE como las de BiblioRed no hay problema.

IN equivale a una cadena de OR, pero es mucho más legible. Existe también NOT IN:

Mismo resultado que antes.

Aviso importante sobre NOT IN y NULL: si la lista contiene un NULL, NOT IN no devuelve ninguna fila, por la lógica de tres valores de la lección 02-01. x NOT IN (1, 2, NULL) equivale a x <> 1 AND x <> 2 AND x <> NULL, y ese último término es siempre DESCONOCIDO. Con listas escritas a mano no ocurre; con listas que vienen de una subconsulta (lección 02-04) es una trampa habitual.

Dos comodines:

LIKE distingue mayúsculas y minúsculas en PostgreSQL:

Ningún título empieza por el en minúscula. Para ignorar la caja, PostgreSQL ofrece ILIKE (la I es de insensitive), que no es estándar pero es comodísimo:

Alternativa portable, válida también en SQLite:

En SQLite, LIKE ya es insensible a mayúsculas para caracteres ASCII (pero no para vocales acentuadas), y no existe ILIKE. Es una de las diferencias que más sorprenden al portar consultas.

Ejemplo con _:

Concretamente devuelve EJ-3081 a EJ-3089: nueve filas, porque EJ-3080 no existe.

Aquí volvemos a la trampa que anunciamos en 02-01.

Y su complementario, que en BiblioRed tiene un significado muy concreto:

Cuatro préstamos abiertos, que coinciden exactamente con los cuatro ejemplares en estado prestado. La base de datos es coherente.

Y una comprobación de la otra trampa de los NULL, la de las desigualdades:

Ninguna de las dos consultas ve los NULL. Si quieres los préstamos "sin recargo pendiente", tienes que decirlo: WHERE recargo = 0 OR recargo IS NULL.

Como una relación es un conjunto y no tiene orden, ORDER BY es la única forma de garantizarlo.

ASC (ascendente) es el valor por defecto; DESC invierte.

Se ordena por el primero y, dentro de los empates, por el segundo:

Cada criterio lleva su propio ASC/DESC: ORDER BY sucursal_id ASC, fecha_alta DESC es perfectamente válido.

¿Dónde va un NULL al ordenar? El estándar deja libertad, y PostgreSQL los coloca al final en ASC y al principio en DESC (equivale a tratarlos como el valor más grande). SQLite hace lo contrario: los pone al principio en ASC.

Como no queremos depender del gestor, se especifica:

Fíjate en el segundo criterio, prestamo_id: sin él, el orden entre los cuatro NULL sería arbitrario. Cuando el orden importe de verdad, termina siempre por un criterio que desempate sin ambigüedad, típicamente la clave primaria.

NULLS FIRST/NULLS LAST es sintaxis estándar y funciona en PostgreSQL; SQLite la admite desde la versión 3.30.

Ordenar por alias es legítimo y legible. Ordenar por número de posición funciona, pero es frágil: si alguien reordena la lista del SELECT, la consulta cambia de sentido en silencio. Evítalo.

ORDER BY titulo sitúa "Álgebra para impacientes" en primer lugar si la base de datos usa una configuración regional española, porque Á se ordena junto a A. Con la configuración C (byte a byte), Á iría después de la Z. No es un fallo: es la colación. Puedes ver la tuya con SHOW lc_collate; en PostgreSQL.

OFFSET salta filas antes de empezar a contar:

Esta es la mecánica de la paginación de cualquier catálogo web: la página N se obtiene con LIMIT tamaño OFFSET (N-1) * tamaño.

Dos advertencias:

1. LIMIT sin ORDER BY no tiene sentido. "Dame 3 filas de las 9" sin decir cuáles significa "dame 3 cualesquiera", y pueden ser distintas en cada ejecución. Peor todavía: si paginas sin ordenar, la misma fila puede salir en la página 1 y en la 3, y otra no salir nunca.
2. OFFSET grande es lento. Para llegar a la fila 100.000 el gestor tiene que producir y descartar las 100.000 anteriores. En catálogos grandes se usan técnicas de paginación por clave; es tema de rendimiento (lección 06-03).

La sintaxis estándar es OFFSET 3 ROWS FETCH FIRST 3 ROWS ONLY, más verbosa y menos usada. LIMIT/OFFSET funciona en PostgreSQL, SQLite y MySQL.

Antes de empezar: los ejemplos de este apartado y del siguiente modifican el juego de datos que acabamos de cargar, y las lecciones 02-04 y 02-05 lo dan por bueno. Al final de cada ejemplo incluimos la instrucción que deshace el cambio. Ejecútala.

Antes de cualquier UPDATE o DELETE, ejecuta la misma condición con un SELECT. Si el SELECT devuelve las filas que esperabas, la modificación también las tocará a ellas.

UPDATE 1 confirma que se ha tocado exactamente una fila. Si ves un número mayor del esperado, algo ha ido mal, y en PostgreSQL, si estás dentro de una transacción, todavía estás a tiempo (lección 06-01).

Un UPDATE puede calcular el valor nuevo a partir del actual:

Importante: recargo + 0.50 sobre un NULL da NULL. Si hubiéramos ejecutado ese UPDATE sin WHERE, los cuatro préstamos abiertos habrían pasado de NULL a… NULL, y los otros ocho habrían subido de precio. Silenciosamente.

Cuando Marta Alsina devuelve EJ-3081, hay que tocar dos tablas:

Esto plantea una pregunta incómoda: ¿qué pasa si la primera instrucción funciona y la segunda falla? La base quedaría en un estado inconsistente: un préstamo cerrado y un ejemplar marcado como prestado. La respuesta es la transacción, y es el contenido de la lección 06-01. De momento, deshacemos:

Y además violaría uq_socios_email, así que en este caso concreto la restricción nos salvaría. No siempre habrá una restricción que te salve. Un UPDATE ejemplares SET estado = 'baja'; habría dado de baja los 40.000 ejemplares de BiblioRed sin protestar.

Costumbres que evitan el desastre:

1. Escribir el WHERE antes que el SET. Empieza tecleando UPDATE tabla WHERE ... y luego vuelve a insertar el SET. Suena raro, funciona.
2. Probar con SELECT primero. Siempre.
3. Trabajar dentro de una transacción en las operaciones delicadas (06-01).
4. En psql, activar \set ON_ERROR_STOP on en los scripts para que se detengan al primer error.

Vamos a crear una fila de usar y tirar para no estropear el juego de datos:

En PostgreSQL puedes usar RETURNING también aquí, para dejar constancia de lo que se llevó por delante:

Intenta borrar un socio que tiene préstamos:

El gestor te está protegiendo. Si permitiera el borrado, los tres préstamos de Marta Alsina quedarían huérfanos: apuntando a un socio que ya no existe. Ese comportamiento —y sus alternativas, como el borrado en cascada— es el tema íntegro de la lección 02-06.

En SQLite, si olvidaste PRAGMA foreign_keys = ON, ese DELETE funcionará y te dejará tres filas huérfanas sin decir nada. Es exactamente el escenario que la lección 02-06 te enseñará a detectar y limpiar.

Sin WHERE, DELETE vacía la tabla entera, sin preguntar y sin papelera. Si te ocurre fuera de una transacción, la única salida es la copia de seguridad (lección 06-04). Las cuatro costumbres del apartado anterior valen aquí con más razón todavía.

Cuando lo que quieres de verdad es vaciar una tabla completa, existe una instrucción específica:

SQLite no tiene TRUNCATE; usa DELETE FROM tabla sin WHERE, que internamente optimiza.

No ejecutes ningún TRUNCATE sobre tu biblioredb: perderías el juego de datos que acabas de cargar. Si ya lo has hecho, vuelve a ejecutar el script del apartado 2.

• UPDATE o DELETE sin WHERE. El error más caro que se comete con SQL. Prueba siempre la condición con un SELECT antes.
• Escribir 'NULL' en lugar de NULL. Con comillas es una cadena de texto de cuatro letras; sin comillas, la ausencia de valor. Una columna que mezcla ambas cosas es una columna arruinada.
• Usar = NULL o <> NULL. Cero filas, sin error. Siempre IS NULL / IS NOT NULL.
• Olvidar que <> valor excluye los NULL. WHERE recargo <> 0 no devuelve los préstamos con recargo nulo. Si los quieres, añade OR recargo IS NULL.
• Mezclar AND y OR sin paréntesis. AND gana. Pon paréntesis siempre.
• INSERT sin lista de columnas. Se rompe en cuanto alguien toca el esquema, a veces en silencio.
• Insertar identificadores explícitos y no resincronizar la secuencia. Provoca errores de clave duplicada mucho después, cuando ya nadie recuerda la carga inicial.
• LIMIT sin ORDER BY. El resultado no es reproducible y la paginación puede repetir u omitir filas.
• Fiarse de que LIKE distingue mayúsculas. En PostgreSQL sí, en SQLite (ASCII) no, en MySQL depende de la colación. Si necesitas certeza, LOWER(columna) LIKE ....
• Consejo: en psql, \pset null '(nulo)' hace visibles los NULL y \x on muestra los resultados en vertical, ideal para filas anchas.
• Consejo: guarda todo el SQL en ficheros (esquema_biblioredb.sql, datos_biblioredb.sql) y ejecútalos con \i fichero.sql en psql o .read fichero.sql en sqlite3. Poder reconstruir la base en diez segundos te dará libertad para experimentar sin miedo.

Todos se resuelven sobre una sola tabla. Escribe la consulta antes de mirar la solución y compara los resultados.

1. Los títulos y editoriales de los libros publicados antes de 2010, del más antiguo al más reciente.
2. Los libros sin ISBN registrado.
3. Las editoriales distintas del fondo, en orden alfabético.
4. Los títulos que contienen la palabra "mar" en cualquier posición, sin distinguir mayúsculas.
5. Los códigos de los ejemplares de la sucursal 2 que no estén disponibles.
6. Los tres libros más recientes del fondo.

1. Los socios dados de alta en 2021 o 2022, con nombre y apellidos en una sola columna llamada socio.
2. Los socios que no están activos.
3. Los préstamos devueltos con retraso (la fecha real de devolución es posterior a la prevista), ordenados por días de retraso… o, si no sabes calcular la diferencia todavía, simplemente por fecha de préstamo.
4. Los préstamos abiertos cuya devolución estaba prevista antes del 10 de agosto de 2026.
5. La segunda página de un listado de préstamos ordenado por fecha de préstamo descendente, con 5 préstamos por página.
6. Los préstamos cuyo recargo no es cero, incluidos aquellos en los que el recargo aún no se ha calculado.

Escribe las instrucciones para cada operación, precedidas del SELECT de comprobación y seguidas de la instrucción que deshace el cambio.

1. El ejemplar EJ-3088 sale del taller: pásalo a disponible.
2. Corrige la editorial del libro 337: pasa de "Ediciones Marlia" a "Ediciones Marlia SL".
3. Da de alta una socia nueva, Berta Colomer ([email protected]), en la sucursal Sur, con fecha de hoy (usa '2026-08-02'), activa, dejando que el gestor le asigne el identificador. Después, bórrala.
4. La reserva 4 estaba cancelada por error: reactívala.

Solución 1

Observa que "El mapa" entra por mapa y "las mareas" por mareas: LIKE busca subcadenas, no palabras completas.

Solución 2

Nótese que la condición compara dos columnas de la misma fila, algo perfectamente legítimo. Y que los cuatro préstamos abiertos no aparecen: NULL > fecha es DESCONOCIDO. En PostgreSQL, fecha_devolucion - fecha_devolucion_prevista daría directamente los días de retraso (7, 7 y 21).

(El segundo criterio prestamo_id DESC garantiza que la paginación sea estable aunque hubiera fechas repetidas.)

Sin el OR recargo IS NULL habrías obtenido solo tres filas y habrías perdido de vista los cuatro préstamos en curso.

Solución 3

Comprobación final de que todo ha quedado como estaba:

Esta lección ha llevado a BiblioRed de un esquema vacío a una base de datos viva y consultable:

• INSERT con lista de columnas explícita (siempre), en una o varias filas, con NULL sin comillas y con RETURNING en PostgreSQL para conocer los identificadores generados. Y la comprobación automática de unicidad y de claves ajenas que la hoja de cálculo nunca tuvo.
• El juego de datos de BiblioRed: 4 sucursales, 8 autores, 10 socios, 9 libros, 15 ejemplares, 12 préstamos y 5 reservas, todo ficticio y coherente. Es el material de trabajo del resto del curso.
• El efecto secundario de insertar claves a mano y cómo resincronizar el generador con RESTART WITH o setval.
• SELECT con proyección de columnas, alias AS (con comillas dobles cuando llevan espacios), concatenación con || y DISTINCT aplicado a la combinación completa de columnas.
• WHERE con comparaciones, AND/OR/NOT y su precedencia, BETWEEN (extremos incluidos), IN y NOT IN (con su trampa con NULL), LIKE/ILIKE con % y _, e IS NULL, que es la única forma de preguntar por la ausencia.
• ORDER BY con varios criterios, ASC/DESC, NULLS FIRST/NULLS LAST y la importancia de un criterio de desempate.
• LIMIT/OFFSET para paginar, siempre con ORDER BY.
• UPDATE y DELETE con la disciplina del SELECT previo, la lectura del número de filas afectadas y el respeto que impone el WHERE olvidado; más TRUNCATE como vaciado rápido de nivel DDL.

Hasta aquí, cada consulta ha mirado una sola tabla, y eso deja preguntas sin responder: no sabemos quién tiene EJ-3081, ni qué título es el más prestado, ni qué socios no han cogido nunca nada. Los datos están repartidos a propósito —esa es la esencia del modelo relacional— y ahora toca recomponerlos.

En la lección 02-04, Consultas Multitabla: JOIN y Subconsultas, aprenderás a unir socios con prestamos, prestamos con ejemplares, ejemplares con libros y libros con autores, todo en una sola consulta; a usar LEFT JOIN para encontrar lo que no tiene correspondencia; y a anidar consultas dentro de consultas. Es donde SQL empieza a resultar realmente potente.