La lección anterior terminaba diciendo que lo que queda por delante no es más temario, sino criterio, y que el criterio se hace con proyectos y con errores propios. Es cierto, pero incompleto: el criterio también se hace leyendo a gente que lleva treinta años cometiendo esos errores y ha tenido la paciencia de escribirlos ordenados. Esta lección es la lista de esa gente.

No es un catálogo. Un catálogo de bibliografía —cuarenta títulos sin jerarquía— no ayuda a nadie: paraliza. Lo que encontrarás aquí son siete bloques temáticos, cada uno con una tabla que dice a qué lección de este curso da continuidad cada libro y para quién no es, y fichas detalladas de los títulos que de verdad merecen tu tiempo. Al final hay un itinerario en tres etapas —tres meses, doce meses, veinticuatro meses— según el perfil profesional hacia el que te dirijas.

Úsala así: no la leas entera de un tirón buscando "el libro bueno". Ve al bloque que corresponde a lo que se te atragantó en el curso, lee la ficha, y compra o pide en la biblioteca un libro. Uno. Cuando lo hayas trabajado —trabajado, no hojeado— vuelve aquí.

Advertencia importante sobre disponibilidad. Las ediciones, los precios, las traducciones al español y la disponibilidad en librerías y bibliotecas cambian constantemente. Los datos de edición que se dan aquí son orientativos y pueden haber quedado atrás cuando leas esto. Antes de comprar nada, verifica en la web de la editorial o del autor qué edición es la vigente. En esta lección no se cita ningún precio, deliberadamente: los precios cambian, las promociones cambian, y lo que hoy tiene edición de bolsillo mañana está descatalogado.

1. Por qué seguir leyendo libros cuando existe la documentación oficial
2. Cómo se lee un libro técnico (no de cabo a rabo)
3. Bloque A — Fundamentos y teoría
4. Bloque B — SQL práctico
5. Bloque C — Diseño y modelado
6. Bloque D — Rendimiento e interioridades del motor
7. Bloque E — NoSQL y sistemas distribuidos
8. Bloque F — PostgreSQL en concreto
9. Bloque G — Clásicos y artículos fundacionales
10. Itinerario de lectura en tres etapas
11. Ediciones, traducciones y cómo conseguir los libros
12. Errores Comunes y Consejos
13. Ejercicios
14. Conclusión

Es una objeción razonable. El manual de PostgreSQL es exhaustivo, está actualizado a la versión exacta que tienes instalada, es gratuito y se busca en dos segundos. ¿Para qué un libro de 900 páginas de 2019?

Porque hacen cosas distintas. La documentación responde "¿cómo se escribe esto?". El libro responde "¿por qué existe esto y cuándo debo usarlo?". Son preguntas diferentes y ninguna sustituye a la otra.

El ejemplo que ya has vivido: la documentación de PostgreSQL describe los cuatro niveles de aislamiento con una tabla impecable de qué anomalía permite cada uno. Es exactamente lo que necesitas para configurar una transacción. Pero lo que hiciste en 06-02 —abrir dos terminales, ver la actualización perdida con tus propios ojos y entender por qué READ COMMITTED es el defecto pese a permitir lecturas no repetibles— eso no está en el manual, y no está porque el manual no es el sitio.

Hay una tercera razón, menos técnica y más honesta: un libro te obliga a un ritmo. La documentación se consulta en ráfagas de dos minutos entre tarea y tarea, y con eso se aprende a resolver el problema de hoy y nada más. Un capítulo leído entero, con la base de datos abierta al lado, deja un poso distinto. Casi todo el mundo que sabe de bases de datos ha leído libros; casi nadie que solo consulte la documentación acaba sabiendo.

Esto importa más que la lista. Un buen libro mal leído no sirve de nada, y la forma habitual de leerlo mal es tratarlo como una novela: empezar por la página 1 con la intención de llegar a la 900, aburrirse en la 60 y abandonarlo.

Un libro técnico no se lee: se trabaja. Este es el método.

Primero, el reconocimiento (30-45 minutos). Antes de leer una sola línea de contenido, léete el índice completo dos veces. Después, hojea el libro entero pasando páginas rápido: mira los títulos de sección, las tablas, los diagramas, los bloques de código. No entiendas nada, solo mira. Al terminar tienes que ser capaz de decir "aquí está lo de los índices", "esta parte es de recuperación ante fallos", "esto último no lo voy a necesitar en años". Ese mapa mental es lo que hará que después encuentres las cosas.

Segundo, elige capítulos, no el libro. Decide qué tres o cuatro capítulos vas a trabajar ahora, y por qué. Los demás existen para cuando los necesites. Un libro de referencia como el de Silberschatz no está escrito para leerse entero fuera de una asignatura universitaria; está escrito para tener el capítulo correcto cuando te hace falta.

Tercero, con la base de datos abierta al lado. Esta es la regla innegociable. Si el libro pone una consulta, la escribes tú, la ejecutas y la rompes a propósito: quítale el GROUP BY, cambia el INNER por LEFT, ponle un NULL donde no lo espera. Lo que aprendes no es el ejemplo del libro, es la diferencia entre el ejemplo y tu versión estropeada. Ten un esquema propio para esto —el de BiblioRed te sirve perfectamente— y traduce los ejemplos del libro a tus tablas. La traducción es la mitad del aprendizaje.

Cuarto, toma notas de decisiones, no de definiciones. No copies "una clave candidata es un conjunto minimal de atributos que...". Eso está en el libro y lo puedes releer. Anota "si tengo una tabla de préstamos con fecha de devolución nula, Karwin dice que el problema no es el NULL sino que estoy modelando dos hechos en una fila". Las notas útiles son las que te discuten un diseño.

Quinto, permítete abandonarlo. Si en tres sesiones no has sacado nada, ciérralo. Puede que no sea tu momento, o que ese libro esté escrito para otra persona. Volver a un libro dos años después y entenderlo entero es una experiencia común y agradable; forzarlo hoy solo produce culpa.

Sexto, releer es normal. Los libros de la categoría D de esta lección se releen. La primera lectura de «Designing Data-Intensive Applications» sin haber sufrido nunca un problema de replicación es útil pero superficial; la segunda, después de haberlo sufrido, es otra cosa.

Son los libros de texto universitarios. Grandes, caros, densos y de referencia: no se leen enteros, se consultan. Su valor es que tratan la materia con rigor y con demostraciones, cosa que un tutorial no hace nunca. Si alguna vez te has preguntado "¿esto de la FNBC de dónde sale exactamente?", la respuesta está aquí.

Qué es. El libro de texto de referencia de la asignatura de bases de datos en medio mundo, desde los años ochenta y con múltiples ediciones. Cubre absolutamente todo el temario clásico: modelo relacional, SQL, diseño, normalización, almacenamiento, indexación, procesamiento y optimización de consultas, transacciones, concurrencia, recuperación, distribución y una parte final de temas modernos.

Qué cubre de este curso. Prácticamente todo lo de los módulos 1, 2, 4, 5 y 6, pero con demostración detrás. Los números de capítulo varían de una edición a otra, así que busca por título en el índice:

Nivel. Universitario de grado. Asume comodidad con notación matemática ligera (conjuntos, funciones) pero no exige más.

Cómo trabajarlo. No lo compres para leerlo: cómpralo (o consíguelo en una biblioteca) para tenerlo. Cuando en el trabajo aparezca "creo que aquí hay una anomalía de actualización", vas al capítulo de diseño relacional, lees veinte páginas y vuelves con la respuesta rigurosa. El capítulo de control de concurrencia es el mejor complemento posible a lo que hiciste en 06-02: allí viste el fenómeno, aquí ves el protocolo de bloqueo en dos fases que lo evita y por qué.

Qué saltarse. La parte de álgebra relacional formal, salvo que te interese; para trabajar no la necesitas. Los capítulos finales de "temas avanzados" envejecen rápido en cada edición. Y el capítulo de SQL, francamente, se aprende mejor en el bloque B.

Qué es. El otro gran libro de texto. Compite directamente con Silberschatz y la elección entre ambos es en buena medida de gusto. Su rasgo diferencial es que dedica mucho más espacio y mucho mejor tratamiento al modelado conceptual.

Qué cubre de este curso. Su territorio natural son los módulos 4 y 5. La parte de modelo ER y ER extendido, y la de transformación de diagramas a esquemas relacionales, es la más completa de los tres libros de este bloque y es la continuación directa de 04-02 y 04-03. También trata a fondo las dependencias funcionales y el algoritmo de descomposición sin pérdida, que en 05-03 aplicaste de forma práctica sin demostrarlo.

Nivel. Universitario, ligeramente más árido que Silberschatz.

Cómo trabajarlo. Si vas a modelar esquemas profesionalmente, lee entera la parte de diseño conceptual, rehaciendo el diagrama de BiblioRed con su notación. Verás que la notación de Elmasri-Navathe difiere de la de patas de gallo que usaste con Mermaid; saber leer las dos es útil porque en la documentación antigua de las empresas te encontrarás ambas.

Qué saltarse. Todo lo demás, honestamente, si ya tienes Silberschatz. Tener los dos es redundante para el 95 % de la gente.

Qué es. Un libro de una tradición distinta. Date fue colega de E. F. Codd y ha dedicado su carrera a defender el modelo relacional en su versión pura, lo que le lleva a criticar SQL con dureza y constancia: los duplicados, los NULL, el orden de las columnas, todo lo que SQL hace y la teoría relacional no permite.

Qué cubre de este curso. Da la fundamentación teórica de 02-01. Después de leerlo, entenderás por qué en aquella lección se insistió en que una relación es un conjunto de tuplas y en que la tabla de SQL no lo es del todo.

Nivel. Alto en exigencia conceptual, aunque no en matemáticas. Es un libro de ideas.

Cómo trabajarlo. Como lectura de discusión, no de consulta. Lee los capítulos sobre relaciones, sobre NULL y sobre integridad, y contrástalos con lo que haces a diario. El capítulo sobre los valores nulos te va a incomodar, y esa incomodidad es productiva: la próxima vez que pongas una columna NULL en BiblioRed te preguntarás si estás representando "no lo sé", "no aplica" o "todavía no", que son tres cosas distintas que SQL confunde en una.

Qué saltarse. Es un libro que puedes leer solo por partes sin ningún problema. Y es perfectamente lícito no leerlo nunca: es el único de esta lección que es una recomendación para una minoría.

Aquí es donde la mayoría de la gente debería empezar. Son libros que se traducen directamente a mejor trabajo la semana siguiente.

Qué es. El libro que más se parece en espíritu a la lección 04-01 de este curso. Cada capítulo presenta un anti-patrón real —con el nombre coloquial que tiene en la profesión— explica por qué la gente cae en él, cuándo es legítimo (siempre hay un caso en que lo es) y cuál es la alternativa correcta.

Qué cubre. Anti-patrones de diseño lógico (listas separadas por comas dentro de una columna, jerarquías mal representadas, claves primarias mal elegidas, uso indebido de NULL, atributos entidad-valor), de diseño físico, de consulta y de desarrollo de aplicaciones, incluida la inyección de SQL.

Nivel. Medio. Necesitas saber SQL, pero no hace falta nada avanzado.

Cómo trabajarlo. Este sí se lee entero y en orden, porque es un argumento acumulativo. Y se lee con el esquema de BiblioRed delante: por cada capítulo, pregúntate si tu esquema comete ese pecado. Encontrarás alguno, y ese ejercicio vale más que cualquier resumen. El capítulo sobre representación de jerarquías conecta directamente con lo que resolviste en el módulo 4 con las categorías de materiales.

Qué saltarse. Nada, es corto. Si tienes prisa, prioriza los capítulos de diseño lógico sobre los de desarrollo de aplicaciones, que son los más ligados a tecnologías concretas y por tanto los que peor envejecen.

Qué es. Un recetario en el sentido literal: doscientos y pico problemas concretos ("cómo encontrar huecos en una secuencia de fechas", "cómo calcular una media móvil", "cómo pivotar filas a columnas") con su solución en SQL, explicada paso a paso y —esto es lo valioso— con la variante para cada motor cuando difieren.

Qué cubre. El territorio del módulo 7, especialmente 07-04. Funciones de ventana, consultas jerárquicas, manipulación de fechas, pivotado, deduplicación, cálculos entre filas consecutivas.

Nivel. Medio-alto. No es para aprender SQL, es para dejar de escribir SQL malo.

Cómo trabajarlo. Por consulta, cuando tengas el problema. Pero hay una excepción: léete entero el capítulo de funciones de ventana, aunque no lo necesites ahora. Es el mayor salto de productividad disponible para alguien que ya sabe GROUP BY, y es exactamente la frontera en la que este curso te ha dejado. Si en 07-04 te costaron las consultas de "el préstamo anterior del mismo socio", este capítulo es tu respuesta.

Qué saltarse. Las secciones de motores que no usas. Si trabajas con PostgreSQL, las variantes de Oracle y SQL Server son ruido en la primera lectura.

Qué es. Un manual de iniciación bien construido, progresivo y con ejercicios. Es el libro que recomendarías a alguien que llega sin haber hecho este curso.

Qué cubre. El módulo 2 completo, con más ejercicios y más despacio. Añade transacciones, vistas, índices y restricciones a nivel introductorio.

Nivel. Iniciación.

Cómo trabajarlo. Si el módulo 2 te resultó cómodo, sáltatelo: no te va a aportar. Si en 02-04 los JOIN y las subconjuntas correlacionadas te costaron —y es lo más común— trabájalo entero, con sus ejercicios, en tres o cuatro semanas. Es el mejor uso posible de ese tiempo. Usa MySQL o el motor que trae el libro para seguir sus ejemplos, o mejor, traduce sus ejemplos a PostgreSQL y a las tablas de BiblioRed.

Qué saltarse. Los capítulos finales de temas avanzados, que están mejor tratados en otros libros de esta lección.

Qué es. Un método completo de diseño de bases de datos relacionales explicado sin una sola fórmula. Donde Elmasri demuestra, Hernandez da una lista de pasos y de preguntas que hacer al cliente.

Qué cubre. El módulo 4 entero, con un enfoque más de proceso que de notación: cómo entrevistar a los usuarios, cómo identificar entidades a partir de lo que dicen, cómo depurar las listas de campos, cómo establecer y validar las relaciones, cómo escribir las reglas de negocio que las restricciones tendrán que implementar. Llega también a la normalización, pero por el camino informal.

Nivel. Accesible. Es el libro de diseño para quien no viene de informática.

Cómo trabajarlo. Aplicando su método a un dominio que no sea el del libro. El ejercicio 1 de esta lección va justo de eso.

Qué saltarse. Su tratamiento de la normalización es correcto pero flojo comparado con lo que ya sabes tras el módulo 5. Si acabas de terminar ese módulo, esa parte te sobra.

Qué es. El libro fundacional del modelado dimensional, es decir, del diseño de bases de datos pensadas para analizar en lugar de para operar. Kimball es quien popularizó el esquema en estrella que se te presentó al final de 05-04 como el ejemplo canónico de desnormalización deliberada.

Qué cubre. Tablas de hechos y tablas de dimensiones, granularidad, dimensiones que cambian lentamente (el famoso problema de "el socio se ha mudado, ¿qué pasa con los préstamos que hizo antes?"), y una colección larguísima de casos por sector.

Nivel. Medio-alto, pero conceptualmente accesible; lo difícil no es entenderlo, es aplicarlo bien.

Cómo trabajarlo. Lee la primera parte —los capítulos de fundamentos dimensionales— y uno solo de los casos sectoriales, el que más se parezca a tu trabajo. Después, diseña el esquema en estrella de los préstamos de BiblioRed: tabla de hechos prestamos, dimensiones socio, material, biblioteca, tiempo. Es el ejercicio 2 de esta lección.

Qué saltarse. Los quince capítulos de casos sectoriales que no te tocan. El libro está pensado para consultarse por sector, no para leerse entero.

Este es, con diferencia, el bloque más importante de la lección para alguien que ya ha hecho este curso. Contiene el libro que se recomienda si solo se va a leer uno.

Qué es. Un libro corto y quirúrgico sobre una sola cosa: cómo funcionan los índices y por qué tus consultas no los usan. Su contenido está también disponible en la web del autor, https://use-the-index-luke.com/, que es una de las referencias más útiles y gratuitas que existen sobre el tema.

Qué cubre. La estructura del B-tree, el orden de las columnas en un índice compuesto (y por qué es la fuente número uno de índices inútiles), predicados que impiden el uso del índice, LIKE con comodín inicial, funciones sobre columnas indexadas, índices que cubren la consulta, ordenación y agrupación que aprovechan el índice, y paginación eficiente.

Nivel. Medio, y sorprendentemente fácil para lo que enseña.

Cómo trabajarlo. Es la continuación exacta de 06-03. Ahí aprendiste a leer un EXPLAIN y a distinguir un recorrido secuencial de uno por índice; aquí aprendes a predecir cuál vas a obtener antes de ejecutar nada. Trabájalo con la base de datos delante y con volumen suficiente: si tus tablas tienen 50 filas, el planificador hará recorrido secuencial siempre y no aprenderás nada. Genera medio millón de préstamos ficticios en BiblioRed (en 09-03 verás cómo) y repite cada ejemplo del libro.

Qué saltarse. Nada. Es corto a propósito. Si tienes que elegir, el capítulo sobre el orden de las columnas en índices compuestos y el de paginación son los que más rendimiento te devuelven por página leída.

Qué es. El libro que hay que leer después de este curso si solo se va a leer uno. No es un libro de bases de datos: es un libro sobre sistemas que manejan datos, que incluye las bases de datos como una pieza. Y es la mejor síntesis existente entre la teoría académica y la práctica industrial.

Qué cubre. Modelos de datos (relacional, documental, grafo) y por qué ganó cada uno donde ganó; motores de almacenamiento y recuperación, con B-trees frente a LSM-trees; codificación y evolución de esquemas; replicación; particionado; transacciones y niveles de aislamiento, con el mejor tratamiento divulgativo que existe del aislamiento snapshot y de la anomalía de escritura sesgada; los problemas de los sistemas distribuidos —relojes, fallos parciales, mentiras de la red—; consistencia y consenso; y una parte final sobre procesamiento por lotes y por flujos.

Nivel. Medio-alto, pero muy bien escrito. Este curso te deja en condiciones de leerlo.

Cómo trabajarlo. Entero y en orden; es un argumento, no una referencia. Ritmo razonable: un capítulo por semana, tomando notas. Sus capítulos de transacciones y de replicación son la continuación natural de 06-01 y 06-02, y toda la última parte es lo que da fundamento a lo que hiciste a ojo en 08-03: cuando el libro habla de change data capture estará describiendo, con nombre propio y con sus modos de fallo estudiados, exactamente el patrón de tabla outbox que usaste para sincronizar PostgreSQL con MongoDB y Elasticsearch. Cada capítulo termina con una bibliografía comentada extensísima que es, en la práctica, un mapa de toda la literatura del campo.

Qué saltarse. Nada en primera lectura, aunque los capítulos de consenso son los más duros y es legítimo dejarlos para una segunda pasada. La web del libro es https://dataintensive.net/.

Qué es. El libro que abre el motor que en 01-04 solo se describió por fuera. Se divide en dos mitades bien diferenciadas: almacenamiento (cómo se guardan de verdad los datos en disco) y sistemas distribuidos (cómo se ponen de acuerdo varias máquinas).

Qué cubre. Formato de páginas y de ficheros, B-trees en detalle y sus variantes reales, LSM-trees y compactación, gestión del búfer, registro de escritura anticipada (el WAL que apareció en 06-01 como garantía de durabilidad), y después difusión de fallos, detectores de fallo, líderes, replicación y consenso.

Nivel. Alto. Es el más exigente de la lección junto con Date.

Cómo trabajarlo. Solo si te pica la curiosidad. No te hará mejor en tu trabajo la semana que viene, pero explica por qué PostgreSQL y Cassandra se comportan tan distinto ante escrituras masivas: uno usa B-trees y el otro LSM-trees, y todo lo demás se deriva de ahí. Lee la primera mitad; la segunda se solapa con Kleppmann y Kleppmann es más legible.

Qué es. Un libro deliberadamente breve que hace lo que su título dice: destilar. Es el origen del término persistencia políglota que estructuró toda la lección 08-03.

Qué cubre. Modelos de agregados, las cuatro familias (clave-valor, documental, familia de columnas, grafo), distribución, consistencia, el teorema CAP explicado sin misticismo, y la elección de motor.

Nivel. Accesible.

Cómo trabajarlo. Es la lectura complementaria del módulo 3. Se lee en dos tardes.

Qué saltarse. Su capítulo de mapa-reducción y algunos ejemplos concretos de producto han envejecido —el panorama de motores NoSQL cambió mucho desde su publicación— pero el marco conceptual sigue siendo el bueno. Léelo por las ideas, no por los productos.

El MongoDB Manual merece estar en una lección de libros porque funciona como uno. Tiene una progresión pensada, capítulos de conceptos y no solo de referencia, y una sección de modelado de datos que es lectura obligatoria después de 03-03. Es gratuito, está siempre actualizado y no envejece. Cuando en 08-02 decidiste incrustar las incidencias dentro del documento de bicicleta en lugar de referenciarlas, estabas aplicando lo que esa sección explica formalmente. Enlace raíz: https://www.mongodb.com/docs/.

PostgreSQL ha sido el motor principal de todo este curso, así que estos dos libros son los de aplicación más inmediata.

Qué es. Un libro con una tesis clara: la mayoría de los desarrolladores usan la base de datos como un almacén tonto y escriben en su lenguaje de aplicación cosas que SQL resuelve mejor. Cada capítulo demuestra la tesis con un caso: una consulta que en la aplicación son doscientas líneas y en SQL veinte, y encima más rápidas.

Qué cubre. SQL avanzado con las herramientas específicas de PostgreSQL: funciones de ventana, expresiones de tabla comunes, LATERAL, tipos de datos ricos (rangos, jsonb, arrays, tipos geométricos), extensiones, y una sección notable sobre modelado.

Nivel. Medio-alto. Necesitas el módulo 2 asentado.

Cómo trabajarlo. Es el complemento perfecto de 07-04. Cógelo capítulo a capítulo y, por cada técnica nueva, busca dónde encajaría en BiblioRed. El capítulo de tipos de rango, por ejemplo, resuelve de un plumazo el problema de reservas solapadas de salas que en el módulo 7 tuviste que atacar con restricciones y comprobaciones manuales: PostgreSQL tiene una restricción de exclusión que lo hace declarativamente.

Qué saltarse. Nada relevante, pero es un libro para consumir despacio.

No lo trates como un simple manual de consulta. Sus partes de Tutorial, The SQL Language y Server Administration son capítulos de libro con todas las de la ley. En 09-02 encontrarás un orden de lectura recomendado para el manual completo; aquí basta con decir que si tuvieras que quedarte con un solo texto sobre PostgreSQL, sería este, y es gratuito.

Aquí hay una idea que conviene defender: leer artículos originales es más fácil de lo que parece y más útil de lo que se supone. La reputación de inaccesibles que tienen los artículos académicos viene del área equivocada; en bases de datos, los artículos fundacionales están escritos por ingenieros que querían que se les entendiera.

Qué es. El artículo que inventó el modelo relacional, publicado en Communications of the ACM, volumen 13, número 6, en junio de 1970. Se citó en 01-03 al contar la historia; aquí la recomendación es que lo leas entero.

Por qué merece la pena. Son unas doce páginas. Y en esas doce páginas está, ya formulado, casi todo lo que has estudiado en los módulos 2, 4 y 5: la independencia de los datos respecto de su representación física, las relaciones como conjuntos de tuplas, las claves, la redundancia y las anomalías, y hasta un primer esbozo de normalización. Leerlo produce un efecto útil: descubrir que las ideas que te han enseñado como "así se hace" fueron una propuesta discutida de una persona concreta contra el consenso de su época, que era el modelo jerárquico y el de red.

Cómo conseguirlo. Está disponible en la biblioteca digital de la ACM (https://dl.acm.org/) y reproducido en múltiples repositorios universitarios. Búscalo por su título exacto; no hace falta ninguna suscripción para encontrar una copia legítima.

Cómo leerlo. Dos pasadas. La primera, entera y sin detenerte, aceptando que la notación de 1970 es distinta de la actual. La segunda, traduciendo su vocabulario al tuyo: donde dice relation piensa tabla, donde dice domain piensa tipo de dato, donde habla de nonsimple domains está anticipando el debate que cincuenta años después reapareció como jsonb y documentos anidados.

Una nota sobre por qué leer originales. Cuando lees un resumen del teorema CAP en un blog, estás leyendo la interpretación de alguien que leyó a alguien que leyó a Brewer. Cada eslabón simplifica y deforma. El caso del CAP es el ejemplo canónico: la versión de blog ("elige dos de tres") es directamente falsa, y el propio Brewer escribió el artículo de 2012 para corregirla. Los originales cuestan una tarde y te vacunan contra una década de simplificaciones repetidas.

Ningún itinerario sirve para todos. Estos tres están construidos a partir de dónde te deja este curso, hacia tres destinos profesionales distintos.

En tabla, con el detalle de por qué cada elección:

Tres avisos sobre el itinerario. Uno: son unos ocho libros en dos años, y eso ya es un ritmo ambicioso para alguien que además trabaja. Si haces la mitad, vas bien. Dos: el orden importa más que la cantidad; leer Kleppmann antes de haber sufrido un problema real de datos es leerlo a medias. Tres: si solo vas a hacer una cosa de toda esta lección, que sea leer «Designing Data-Intensive Applications» durante el próximo año, sea cual sea tu perfil.

Ediciones. Los libros de texto del bloque A van por ediciones muy avanzadas y cada nueva edición reordena capítulos y añade temas modernos. Para el uso que vas a darles, una edición anterior sirve perfectamente y es mucho más fácil de conseguir: la teoría relacional y las formas normales no han cambiado. Donde sí importa la edición reciente es en los libros ligados a un producto —PostgreSQL, MongoDB— porque las versiones del motor avanzan y los ejemplos dejan de funcionar.

Traducciones al español. La situación es desigual y cambia con el tiempo. Los libros de texto clásicos han tenido traducciones al español en algún momento, a veces de ediciones antiguas; los libros más recientes y los de editoriales técnicas pequeñas suelen estar solo en inglés. Verifica antes de comprar y no des por hecho que existe versión en español de un título concreto. Dicho sin rodeos: el inglés técnico de lectura es, a estas alturas, parte del oficio, y es mucho más fácil de lo que parece porque el vocabulario es el que ya conoces.

Dónde conseguirlos. Bibliotecas universitarias (los libros del bloque A están en todas las de escuelas de informática), bibliotecas públicas con préstamo interbibliotecario, ediciones electrónicas de las propias editoriales, y las suscripciones de lectura técnica que muchas empresas ya pagan sin que sus empleados lo sepan —pregunta en tu trabajo antes de comprar nada—. Varios de los recursos citados son gratuitos y legales: el manual de PostgreSQL, el MongoDB Manual, el contenido de use-the-index-luke.com y el artículo de Codd.

Y de nuevo, la advertencia que abre la lección: disponibilidad, ediciones vigentes, formatos y precios cambian. Comprueba siempre en la fuente oficial —web de la editorial o del autor— antes de comprar.

Error 1: comprar cinco libros de golpe. Es la forma más eficaz de no leer ninguno. La pila de libros sin leer genera culpa, y la culpa genera evitación. Uno cada vez.

Error 2: empezar por el más gordo. Silberschatz tiene novecientas páginas y parece "el completo", así que mucha gente empieza por ahí y abandona en el capítulo 3. Empieza por «SQL Antipatterns» o por «SQL Performance Explained», que son cortos, se acaban y dan resultados visibles. Terminar un libro técnico genera el impulso para el siguiente.

Error 3: leer sin teclado. Ya se ha dicho y se repite porque es el error dominante. Un libro técnico leído en el metro es entretenimiento; leído con la base de datos abierta es formación.

Error 4: creer que la edición antigua no vale. Para teoría, la edición de hace quince años es idéntica en lo que te importa. No dejes de leer un clásico porque solo encuentres una edición vieja.

Error 5: confundir "conocido" con "adecuado para mí ahora". «Database Internals» es un libro excelente y es una pérdida de tiempo para quien todavía duda con los LEFT JOIN. El mejor libro es el que está un escalón por encima de donde estás, no cinco.

Error 6: no releer. Los tres o cuatro libros centrales de tu carrera se releen cada pocos años y cada vez dicen algo distinto, porque quien ha cambiado eres tú.

Consejo 1: lleva una lista de "conceptos que no entendí". Cada vez que un libro mencione algo que no conoces —write-ahead log, LSM-tree, dimensión que cambia lentamente— anótalo en vez de detenerte. Al acabar el capítulo, resuelve los tres más repetidos. Detenerte en cada uno hace que no termines nunca.

Consejo 2: usa siempre el mismo esquema de prácticas. Traduce todos los ejemplos de todos los libros a BiblioRed o a VallBici. Tener un dominio propio que conoces al dedillo convierte cada ejemplo nuevo en una comparación, y las comparaciones se recuerdan.

Consejo 3: la bibliografía de un buen libro es un mapa. Kleppmann termina cada capítulo con decenas de referencias comentadas. Cuando un tema te enganche, esa bibliografía es mejor guía que cualquier búsqueda en internet.

Consejo 4: desconfía de las listas sin criterio, incluida esta si no la contrastas. Que un libro esté aquí significa que a mucha gente le ha servido, no que te vaya a servir a ti. Hojea antes de comprometer treinta horas.

Estos ejercicios no son de memoria: son de planificación y de práctica real. No tienen una única respuesta correcta, y las soluciones que siguen son respuestas modelo razonadas, no la respuesta. Tu itinerario será distinto del que aparece aquí y estará bien si el razonamiento se sostiene.

Diseña tu propio plan de lectura para los próximos doce meses. Debe incluir, obligatoriamente:

1. Una autoevaluación honesta: de las 33 lecciones anteriores de este curso, ¿cuáles son las tres que peor dominas? Sé concreto (no "el módulo 6", sino "no sabría decidir entre READ COMMITTED y REPEATABLE READ para el cierre de un préstamo").
2. Un perfil objetivo entre los tres del apartado 10, o una mezcla justificada.
3. Tres libros como máximo, con el orden en que los leerás y por qué en ese orden.
4. Para cada libro: qué capítulos concretos trabajarás primero y cuáles pospondrás.
5. Un entregable por libro: algo construido sobre BiblioRed o VallBici que demuestre que lo has trabajado.
6. Una estimación realista de horas semanales y la fecha en que revisarás el plan.

Elige uno de estos dos encargos y desarróllalo hasta el punto en que puedas defenderlo por escrito en una página:

Opción A (Kimball). Diseña el esquema en estrella para el análisis de préstamos de BiblioRed: identifica la tabla de hechos, su granularidad exacta, sus medidas, y las dimensiones necesarias. Resuelve explícitamente el problema de la dimensión que cambia lentamente: un socio se muda de barrio; ¿los préstamos que hizo el año pasado deben atribuirse al barrio antiguo o al nuevo? Justifica la decisión y explica cómo la implementarías.

Opción B (Karwin). Audita el esquema relacional de BiblioRed de los módulos 4 y 5 buscando anti-patrones: columnas multivaluadas, claves primarias sin criterio, jerarquías mal representadas, usos ambiguos de NULL, atributos entidad-valor encubiertos. Enumera los que encuentres —o los que estuviste a punto de introducir— y, para cada uno, di cuál sería la alternativa y en qué caso el anti-patrón habría sido aceptable.

Localiza y lee entero el artículo de E. F. Codd de 1970, «A Relational Model of Data for Large Shared Data Banks». Después responde por escrito, en no más de una página:

1. ¿Qué problema concreto de los sistemas de su época dice Codd que viene a resolver?
2. Señala dos ideas del artículo que hayas estudiado en este curso y di en qué lección aparecieron.
3. Señala una idea del artículo que este curso no haya tratado, o que haya tratado de forma distinta.
4. ¿Hay algo en el artículo que hoy consideraríamos superado o equivocado?

Recuerda: son respuestas modelo, no las únicas correctas. Lo que se evalúa es la calidad del razonamiento, no la coincidencia con lo que sigue.

Solución 1 (respuesta modelo)

Un plan bien construido, para un perfil de desarrollo de aplicaciones back-end:

Autoevaluación. (a) No sé predecir si el planificador usará un índice; en 06-03 entendí el EXPLAIN a posteriori pero no anticipo el plan. (b) En 05-03 normalicé siguiendo el procedimiento, pero ante un esquema ajeno no sabría detectar la dependencia transitiva sin que me la señalen. (c) En 08-03 entendí la sincronización con tabla outbox pero no sabría razonar qué pasa si el proceso que la lee se cae a medias.

Perfil. Desarrollo de aplicaciones, con un pie en administración porque en mi equipo no hay especialista.

Libros y orden.

Entregables.

1. Un documento con cinco consultas lentas de BiblioRed sobre 500.000 préstamos ficticios, su plan antes y después, el índice creado en cada caso y la justificación del orden de sus columnas.
2. Una auditoría escrita del esquema de BiblioRed con los anti-patrones detectados y la corrección propuesta de cada uno.
3. Una implementación funcionando del patrón outbox de 08-03 entre PostgreSQL y MongoDB, con una prueba deliberada: matar el proceso lector a mitad de lote y documentar qué ocurre y por qué no se pierde ningún evento.

Ritmo. Cuatro horas semanales, en dos sesiones de dos horas. Revisión del plan a los tres meses: si a esas alturas no he terminado el primer libro, el problema es el ritmo, no el libro, y reduzco el plan a dos libros.

Solución 2 (respuesta modelo, opción A)

Tabla de hechos: hechos_prestamo.

Granularidad: una fila por préstamo individual de un ejemplar. Es la decisión más importante del diseño y hay que declararla antes de elegir ninguna columna. Se elige la granularidad más fina disponible porque desde ella se puede agregar a cualquier nivel (mes, biblioteca, categoría), mientras que desde una tabla ya agregada no se puede descender.

Medidas: dias_prestamo, dias_retraso, importe_multa, y un contador implícito (cada fila es un préstamo).

Dimensiones: dim_socio, dim_material, dim_ejemplar, dim_biblioteca, dim_tiempo_prestamo, dim_tiempo_devolucion. Las dos dimensiones de tiempo apuntan a la misma tabla de calendario con dos papeles distintos.

La dimensión que cambia lentamente. El socio se muda de barrio. Hay tres tratamientos clásicos y la elección depende de la pregunta de negocio:

Decisión para BiblioRed: nueva fila versionada. Razón: el uso analítico principal es medir la actividad lectora por barrio a lo largo del tiempo para decidir dónde reforzar la colección. Si al mudarse un socio se reescribiera su historia, el informe del año pasado cambiaría cada vez que alguien se muda, y un informe que cambia hacia atrás no sirve para tomar decisiones ni para rendir cuentas. La tabla de hechos guarda la clave subrogada de la versión vigente en el momento del préstamo, no el identificador natural del socio.

Matiz honesto: si la pregunta de negocio fuera "¿dónde viven hoy nuestros socios más activos?", el tratamiento por sobrescritura sería el correcto y el versionado, un exceso. La respuesta depende de la pregunta, y por eso el diseño dimensional empieza siempre por las preguntas y no por las tablas.

Solución 3 (respuesta modelo)

1. El problema. Codd señala que en los sistemas de su época —jerárquicos y de red— los programas de aplicación dependían de cómo estaban almacenados y ordenados físicamente los datos: cambiar un índice, un orden o una estructura de punteros obligaba a reescribir programas. Su propuesta busca la independencia de los datos respecto de su representación interna.

2. Dos ideas ya vistas. (a) Las relaciones como conjuntos de tuplas sobre dominios, con el orden de las filas irrelevante: es el fundamento de 02-01. (b) La eliminación de la redundancia y las anomalías derivadas, con el germen de la normalización: 05-01 y 05-02.

3. Una idea tratada de otra forma. Codd desarrolla un cálculo y un álgebra de relaciones como lenguaje de consulta; este curso ha usado directamente SQL, que es una implementación comercial parcial y no del todo fiel de aquellas ideas (SQL admite duplicados y orden, cosas que la relación pura no tiene). Ese desajuste es justo lo que C. J. Date lleva décadas señalando.

4. Qué ha quedado atrás. La preocupación por el coste del almacenamiento y por la eficiencia de las representaciones, muy presente en el artículo, tiene hoy otra escala; y su tratamiento de los dominios no simples —relaciones dentro de relaciones— quedó fuera del modelo relacional práctico, aunque reapareció décadas después por otra puerta con los tipos jsonb y los documentos anidados que usaste en el módulo 3. Nada del núcleo del artículo está superado, que es exactamente lo notable de un texto de más de cincuenta años.

Un módulo de recursos corre siempre el riesgo de ser una lista, y una lista sin criterio no vale nada. Por eso esta lección ha insistido más en cómo leer y en qué orden que en cuántos títulos existen.

Tres cosas para llevarse.

La primera: el libro y la documentación hacen trabajos distintos. La documentación de PostgreSQL te dirá siempre la sintaxis exacta de CREATE INDEX y nunca te dirá si ese índice tiene sentido. Para lo segundo hace falta alguien que haya visto mil índices inútiles y se haya sentado a escribir por qué lo eran. Sigue usando el manual a diario —es excelente— y lee libros aparte.

La segunda: un libro técnico se trabaja, no se lee. Con el teclado delante, traduciendo cada ejemplo a un esquema que conozcas, rompiendo las consultas a propósito y anotando decisiones en lugar de definiciones. Un capítulo trabajado así vale por diez leídos en el sofá.

Y la tercera: menos libros y más veces. Si de toda esta lección te llevas un solo título, que sea «Designing Data-Intensive Applications» de Martin Kleppmann para los próximos doce meses; y si quieres un resultado visible en tres semanas en lugar de en un año, empieza por «SQL Performance Explained» de Markus Winand, que es la continuación exacta de 06-03 y se acaba en unas pocas tardes. Y ten presente lo que se ha repetido: ediciones, traducciones, disponibilidad y precios cambian; verifica siempre en la fuente oficial antes de comprar.

Los libros dan orden y criterio, pero son un formato lento y solitario. La lección 09-02 cubre el otro lado del aprendizaje autónomo: la documentación oficial estudiada en serio, las plataformas donde se practica SQL con corrección automática, los cursos universitarios publicados en abierto, y cómo construir con todo ello un plan de estudio de doce semanas que empiece exactamente donde este curso te ha dejado.