En 09-01 vimos el aprendizaje lento: libros, capítulos trabajados con el teclado delante, un título cada tres meses. Esta lección cubre el otro lado, el que da resultados en semanas: documentación oficial estudiada en serio, plataformas donde escribes SQL y alguien te corrige al instante, cursos universitarios publicados en abierto, y las fuentes que te mantienen al día una vez que el curso se acaba.

También cubre algo que casi nadie explica y que ahorra meses: cómo distinguir un curso que enseña de uno que entretiene. Hay una cantidad enorme de material sobre bases de datos en línea, y buena parte es el mismo SELECT * FROM clientes repetido durante nueve horas de vídeo. Aprender a descartar rápido es una habilidad tan valiosa como saber elegir.

La lección termina con una plantilla concreta de plan de estudio de doce semanas, construida exactamente sobre el punto en que este curso te ha dejado: alguien que ha diseñado y normalizado un esquema, ha escrito consultas multitabla y con agregación, ha leído un plan de ejecución, ha modelado documentos en MongoDB y ha repartido un sistema entre cuatro motores.

Advertencia importante. La disponibilidad de los cursos, sus precios, sus planes gratuitos, sus contenidos y hasta su existencia cambian constantemente. Las plataformas retiran cursos, las universidades reorganizan sus programas y los planes gratuitos se recortan o se amplían sin aviso. En esta lección no se cita ningún precio y no se dan enlaces profundos: para cada curso se indica su título exacto y la institución que lo imparte, y la instrucción es que lo busques por ese título en la plataforma correspondiente. Antes de matricularte o pagar nada, verifica en la fuente oficial qué hay disponible hoy.

1. Cómo elegir un curso en línea sin perder el tiempo
2. La documentación oficial como primer recurso
3. Cómo se estudia el manual de PostgreSQL
4. La documentación de los demás motores
5. Plataformas de práctica interactiva
6. Cursos estructurados de universidades y plataformas
7. Blogs, canales y boletines para mantenerse al día
8. Certificaciones: para quién sí y para quién no
9. Tu plan de estudio personal: plantilla de 12 semanas
10. Errores Comunes y Consejos
11. Ejercicios
12. Conclusión

Antes de la lista, el filtro. Estas son las señales que se pueden comprobar en diez minutos, antes de invertir cuarenta horas.

La sintaxis de SQL es pequeña. Lo esencial cabe en un par de tardes, y este curso ya te la dio en el módulo 2. Lo que cuesta años es lo otro: decidir. Si esa columna debe admitir NULL, si esa tabla debe partirse, si ese índice va a servir de algo, si ese JOIN debería ser una subconsulta, si esa operación necesita una transacción y con qué nivel de aislamiento.

Un curso que solo enseña sintaxis produce una sensación agradable de progreso —cada lección añade una palabra clave nueva— y deja al alumno incapaz de diseñar nada. Es la razón por la que este curso dedicó dos módulos enteros (4 y 5) a diseño y normalización antes de considerar terminado el asunto, y por la que los módulos 7 y 8 fueron todo ejercicios y casos.

Cuando evalúes un curso, busca la parte de decisiones. Si no la tiene, no importa cuántas horas dure.

Dicho sin adornos: en una entrevista técnica, un certificado de finalización de una plataforma abierta pesa muy poco, y un repositorio con un esquema bien diseñado, sus migraciones, sus índices justificados y un README que explica las decisiones pesa mucho.

La razón no es esnobismo. El certificado prueba que viste el material; el proyecto prueba que tomaste decisiones bajo restricciones y que sabes defenderlas. Y las decisiones son el trabajo.

Por eso, en el plan de doce semanas del apartado 9, cada bloque tiene un entregable, y el certificado no aparece por ninguna parte.

La costumbre más extendida y más costosa es buscar en internet antes que en el manual. Se hace porque el manual "es denso" y la respuesta de un foro "es más rápida". Es cierto a corto plazo y falso a medio: la respuesta del foro es de 2013, está escrita para otra versión, resuelve un caso parecido pero no el tuyo, y no te enseña dónde mirar la próxima vez.

Empieza siempre por la documentación oficial. Y no solo para consultas puntuales: estúdiala por bloques, como si fuera un libro, porque en varios de estos motores lo es.

Dos advertencias sobre documentación. Primera: fíjate siempre en la versión. El manual de PostgreSQL se publica por versión y es fácil acabar leyendo el de una versión que no tienes instalada; comprueba el selector de versión de la página. Segunda: la documentación oficial manda sobre cualquier curso, blog o respuesta de foro. Si un vídeo dice una cosa y el manual dice otra, el manual tiene razón.

El manual de PostgreSQL asusta por su tamaño, y no debería: está organizado en partes con propósitos muy distintos, y solo dos o tres son lectura seguida. Este es un orden de lectura razonable para alguien que termina este curso.

Un método que funciona bien: una sección del manual por semana, con un cuaderno de consultas propio. Por cada sección, escribe cinco consultas contra BiblioRed que usen algo que acabas de descubrir. La sección de tipos de datos, por ejemplo, casi seguro te hará reescribir un par de columnas de tu esquema en cuanto descubras los tipos de rango y timestamptz.

MongoDB Manual y MongoDB University. El manual (https://www.mongodb.com/docs/) tiene una sección de modelado de datos que es lectura obligada tras 03-03: formaliza el criterio de incrustar frente a referenciar que aplicaste a ojo en 08-02, con sus patrones con nombre. Aparte del manual, MongoDB mantiene MongoDB University, una plataforma de formación propia con rutas de aprendizaje para desarrollo y administración, accesible desde el sitio oficial de MongoDB. Es de las formaciones de producto mejor hechas que existen. Como todo lo demás en esta lección: comprueba en el sitio oficial qué rutas hay disponibles hoy y en qué condiciones, porque cambian.

SQLite. Su documentación tiene una particularidad rara y valiosa: además de la referencia, publica documentos de opinión y de diseño —cuándo usar SQLite y cuándo no, por qué su sistema de tipos es dinámico, qué limitaciones son deliberadas—. Leer esas páginas es la mejor continuación de 01-02, porque explican con honestidad para qué sirve una base de datos embebida y para qué no. Raíz: https://sqlite.org/.

Redis. La documentación (https://redis.io/docs/) está organizada por tipos de datos, y esa organización es en sí misma la enseñanza: entender qué resuelve un conjunto ordenado frente a una lista frente a un hash es entender Redis. La parte de caducidad de claves y la de persistencia son las que dan fundamento a lo que hiciste en 08-03 con la disponibilidad en tiempo real de VallBici.

Neo4j. Su documentación (https://neo4j.com/docs/) incluye material de aprendizaje del lenguaje Cypher y de modelado de grafos. Neo4j fue el motor que en 03-02 se mencionó y no se practicó; si quieres cubrir ese hueco, es el mejor sitio para hacerlo, y el modelado de grafos tiene un efecto secundario interesante: te obliga a pensar en relaciones como ciudadanas de primera clase, lo que cambia cómo ves el modelo relacional.

Elasticsearch. La documentación en https://www.elastic.co/ cubre el análisis de texto, los mapeos y el lenguaje de consulta. Lo que conviene estudiar tras 08-03 es la parte de analizadores: entender qué le pasa a un texto entre que se indexa y que se busca es lo que explica por qué Elasticsearch encuentra "Vallmar" cuando escribes "valmar" y ILIKE no.

Escribir SQL y que algo te diga inmediatamente si está bien es, para aprender consultas, más eficaz que cualquier vídeo. Estas son las plataformas consolidadas.

Ese último punto merece énfasis: las plataformas interactivas enseñan a consultar, no a diseñar. Cubren perfectamente el módulo 2 y buena parte del 7, y no cubren los módulos 4, 5 y 8. No hay atajo para el diseño: se aprende diseñando y sometiendo el diseño a crítica.

Aquí se dan títulos exactos e institución. Búscalos por ese título en la plataforma correspondiente; los catálogos y las direcciones cambian, y por eso no se enlaza a fichas concretas.

Qué es. Carnegie Mellon publica en abierto, curso tras curso, sus asignaturas de sistemas de bases de datos: las clases grabadas, las transparencias, los enunciados de los proyectos. Es material universitario de primer nivel disponible sin matrícula.

Qué cubre. El curso de introducción recorre almacenamiento, formatos de página, índices B-tree, procesamiento de consultas, planificación y optimización, control de concurrencia, recuperación y sistemas distribuidos. El de posgrado va a fondo en motores modernos, ejecución vectorizada y almacenamiento en columnas.

Nivel. Alto. Es un curso de informática, con programación de sistemas en los proyectos.

Cómo trabajarlo. No lo intentes entero de entrada. Es la continuación perfecta de 01-04 —donde se describió la arquitectura de un gestor por fuera— y de 06-03 —donde leíste planes de ejecución sin saber cómo se generan—. Empieza viendo únicamente las clases de índices, procesamiento de consultas y optimización de consultas, en ese orden. Si te enganchan, sigue; si no, ya has sacado lo principal.

Qué saltarse. Los proyectos de programación, salvo que quieras dedicarte a construir motores. Ver las clases sin hacer los proyectos ya aporta muchísimo.

Qué es. El material del curso clásico de bases de datos de Stanford, reorganizado en varios mini-cursos autoguiados, cada uno centrado en un bloque. Es probablemente el curso en línea de bases de datos más veterano y más pulido que existe.

Qué cubre. Modelo relacional y SQL, diseño y teoría —incluidas dependencias funcionales y formas normales, con más rigor del que dio el módulo 5—, datos semiestructurados (XML, JSON), y temas avanzados de SQL como vistas, disparadores y restricciones.

Nivel. Medio, con partes teóricas exigentes.

Cómo trabajarlo. Si en 05-02 te quedaste con la sensación de haber aplicado las formas normales sin entender del todo su fundamento, el mini-curso de modelado y teoría es exactamente el remedio. Los ejercicios tienen corrección automática, lo que para teoría es raro y muy valioso.

Qué saltarse. La parte de XML, salvo interés específico; hoy pesa mucho menos de lo que pesaba cuando se grabó.

Terminado el curso, el problema deja de ser aprender y pasa a ser no oxidarse. La trampa aquí es suscribirse a treinta fuentes, no leer ninguna y sentirse mal. La estrategia que funciona es la contraria: dos o tres fuentes fijas y un rato fijo a la semana.

Sobre Jepsen, una nota: es el sitio donde las afirmaciones comerciales sobre consistencia se ponen a prueba de verdad. Después de 06-02 y 08-03, leer un informe de Jepsen sobre un motor que creías conocer es una experiencia formativa notable, porque muestra la distancia entre lo que un producto promete en su web y lo que garantiza bajo partición de red.

Cómo no ahogarse. Tres reglas. Una: los agregadores se leen por titulares, no por artículos; abres dos, no doce. Dos: si un tema no te toca en el trabajo ni en un proyecto propio, leer sobre él es entretenimiento, no formación —lo cual está bien, pero no lo cuentes como estudio—. Tres: reserva un rato fijo, treinta minutos semanales, y fuera de ese rato no leas nada. La actualidad técnica no es urgente casi nunca.

Las certificaciones existen en tres familias: las de producto de base de datos (por ejemplo, las certificaciones oficiales de MongoDB para desarrollo y administración, o las que ofrecen las empresas que dan soporte comercial a PostgreSQL), las de proveedor de nube (los tres grandes tienen certificaciones de datos y de bases de datos, con catálogos que reorganizan a menudo) y las de plataforma de formación, que en realidad son certificados de finalización y no certificaciones.

Dos cautelas. Primera: los catálogos, nombres, códigos y requisitos de las certificaciones cambian con frecuencia —se retiran exámenes, se renombran, se fusionan—; consulta siempre el catálogo oficial del proveedor y no te fíes de listas de terceros, incluida esta. Segunda: el mayor valor de una certificación no suele ser el diploma, sino que su temario oficial es una lista de comprobación excelente de lo que deberías saber. Puedes usar ese temario como plan de estudio sin presentarte nunca al examen, y es una estrategia perfectamente legítima.

Un plan de estudio necesita cinco cosas: horas semanales realistas, temas ordenados, un recurso concreto por tema, un entregable por bloque y una fecha de revisión. Sin entregable no es un plan, es una lista de deseos.

Este es el esqueleto, pensado para escribirse en un fichero y versionarse junto a tu proyecto.

Y esta es una instancia completa de la plantilla, para un perfil de desarrollo de aplicaciones. Sirve como ejemplo de nivel de concreción, no como plan universal.

Cómo detectar que un curso lleva años sin tocarse (relevante al elegir los recursos de tu plan): la versión del motor que aparece en las capturas está varias versiones por detrás de la actual; se usan herramientas cuya interfaz ya no se parece a la real; los comentarios recientes preguntan por qué un paso ya no funciona; el temario ignora funcionalidades que hoy son estándar en el motor; y no hay fecha de actualización visible por ninguna parte. Cualquiera de esas señales no invalida un curso de teoría —la normalización no ha cambiado—, pero descarta uno de producto.

Error 1: coleccionar cursos. Matricularse en seis cursos y no terminar ninguno es un patrón tan común que tiene nombre propio en las plataformas. Uno cada vez, con su entregable, y hasta que no esté el entregable no empieza el siguiente.

Error 2: ver vídeo sin escribir código. Ver a alguien escribir SQL produce la ilusión completa de haber aprendido, y esa ilusión se deshace en cuanto tienes el cursor parpadeando en una consulta en blanco. Pausa el vídeo, escribe tú, y cuando funcione, rómpelo a propósito.

Error 3: buscar en un foro antes que en el manual. La respuesta del foro resuelve el síntoma de hoy; el manual te enseña dónde estará la respuesta de mañana. Y en un porcentaje sorprendente de casos, la respuesta del foro es de una versión que ya no existe.

Error 4: perseguir el certificado en lugar del proyecto. Ya se ha dicho: un esquema bien diseñado y documentado en un repositorio público pesa más en una conversación técnica que cualquier diploma de finalización.

Error 5: estudiar un motor que no vas a usar. Aprender Cassandra "por si acaso" cuando trabajas con PostgreSQL es tiempo que rinde poco. La excepción legítima es estudiar un motor de familia distinta para entender el contraste, que es justo lo que hizo el módulo 3 de este curso: no para usar Neo4j, sino para ver el modelo relacional desde fuera.

Error 6: no fijar hora. "Estudiaré cuando pueda" significa no estudiar. Dos franjas fijas en el calendario, con aviso, y trátalas como una reunión.

Consejo 1: mezcla siempre un recurso lento y uno rápido. Un libro en marcha (formato de 09-01) y una plataforma de práctica en marcha. El libro da criterio, la práctica da soltura, y cada uno hace llevadero al otro.

Consejo 2: escribe lo que aprendes. Una nota corta por sesión —qué probé, qué falló, qué entendí— convierte horas dispersas en algo consultable. Y si te atreves a publicarlas, escribir para otros es el mejor detector de lagunas propias que existe.

Consejo 3: traduce todo a tu dominio. Los ejercicios de PGExercises van de un club deportivo; reescribe tres de ellos contra BiblioRed. La traducción es donde se aprende, porque obliga a entender la consulta en lugar de copiarla.

Consejo 4: usa los temarios oficiales como listas de comprobación. El temario de una certificación o el índice de un curso universitario son inventarios muy trabajados de lo que hay que saber. Aprovéchalos aunque no te matricules.

Estos ejercicios son de planificación y de práctica real, no de memoria. No tienen una única respuesta correcta: las soluciones son respuestas modelo razonadas, y la tuya será distinta y podrá ser igual de buena si el razonamiento se sostiene.

Rellena la plantilla plan-estudio.yml del apartado 9 con tu caso real. Requisitos mínimos:

1. Tres puntos débiles concretos, citando la lección donde aparecieron (no "SQL", sino "en 07-04 no supe resolver el préstamo anterior del mismo socio sin subconsulta correlacionada").
2. Un perfil objetivo justificado.
3. Horas semanales que puedas cumplir de verdad, con día y hora fijos.
4. Cuatro bloques de tres semanas, cada uno con recursos nombrados y un entregable verificable.
5. Un criterio de éxito por bloque que no sea "haberlo leído".
6. Una fecha de revisión intermedia y las preguntas que te harás en ella.

Busca tres cursos en línea sobre bases de datos o SQL: uno de una universidad, uno de una plataforma comercial y uno gratuito de una comunidad o de un fabricante. Sin matricularte en ninguno, en veinte minutos por curso, rellena esta tabla y decide cuál harías y por qué:

Añade una frase final: qué parte de ese curso te saltarías, dado lo que ya sabes tras este.

Durante una semana, prohíbete buscar en internet cualquier duda de PostgreSQL: solo el manual oficial. Elige una sección de la tabla del apartado 3 que no hayas trabajado (por ejemplo, Data Types o Indexes), léela entera y produce:

1. Cinco consultas o sentencias DDL contra BiblioRed que usen algo que has descubierto en esa sección y que antes no conocías.
2. Un cambio en el esquema de BiblioRed que harías a la luz de lo leído, con su justificación.
3. Tres cosas que creías saber y estaban mal o incompletas.
4. Una valoración honesta: ¿cuánto más lento fue que buscar en internet, y compensó?

Son respuestas modelo. Lo que se evalúa es el razonamiento, no la coincidencia.

Solución 1 (respuesta modelo)

Lo que hace bueno a este plan no es su ambición, sino tres cosas: los puntos débiles están citados por lección, los entregables son verificables por un tercero, y hay un mecanismo explícito para recortar en la revisión en lugar de abandonar.

Solución 2 (respuesta modelo)

Un veredicto típico, con los tres perfiles habituales:

Qué me saltaría del A: los proyectos de programación, salvo interés en construir motores. Del C: los módulos introductorios de CRUD, ya cubiertos por 03-03 y 08-02.

La conclusión importante del ejercicio suele ser esta: después de este curso, la mayoría de los cursos generalistas de SQL ya no te aportan nada, y el tiempo rinde mucho más en documentación oficial, práctica corregida y material universitario de nivel alto.

Solución 3 (respuesta modelo, sección Data Types)

1. Cinco cosas nuevas aplicadas a BiblioRed.

2. Cambio de esquema justificado. Sustituir fecha_inicio/fecha_fin de reservas_sala por un tstzrange con restricción de exclusión. Motivo: la regla "dos reservas de la misma sala no pueden solaparse" pasa de ser una comprobación en la aplicación —que falla bajo concurrencia, justo el problema de 06-02— a ser una restricción del motor, que no falla nunca. Es el mismo principio de 02-06: si la regla es de integridad, vive en la base de datos.

3. Tres cosas que creía saber y estaban mal.

• Creía que timestamp y timestamptz se diferenciaban en que uno guarda la zona horaria. No la guarda: timestamptz normaliza a UTC al almacenar y convierte a la zona de la sesión al leer. Eso cambia cómo hay que pensar los informes por franja horaria.
• Creía que varchar(n) era más eficiente que text en PostgreSQL. No lo es; el límite es una restricción, no una optimización, y ponerlo sin motivo solo genera migraciones futuras.
• No sabía que existían los tipos de rango ni las restricciones de exclusión, y llevaba resolviendo a mano un problema que el motor resuelve declarativamente.

4. ¿Compensó? Fue claramente más lento: leer la sección entera costó unas tres horas frente a los dos minutos de una búsqueda puntual. Compensó, y mucho, porque los tres hallazgos anteriores no se pueden buscar: no sabía que existían, y por tanto no habría formulado nunca la consulta que los encontraría. Ese es el argumento a favor de leer documentación por bloques en lugar de solo consultarla: resuelve el problema de las cosas que no sabes que no sabes.

Esta lección se puede resumir en cuatro decisiones.

La primera: empieza por la documentación oficial, y estúdiala por bloques. El manual de PostgreSQL no es solo una referencia para consultar dudas: leído sección a sección, con un cuaderno de consultas propio, es el mejor curso disponible sobre el motor, y es gratuito. Lo mismo vale para el MongoDB Manual, para la documentación de SQLite —cuyos documentos de diseño son lectura formativa por sí mismos— y para Redis, Neo4j y Elasticsearch cuando los necesites. La documentación oficial manda sobre cualquier curso.

La segunda: practica donde te corrijan. PGExercises, SQLZoo, SQLBolt para lo básico, HackerRank y LeetCode para volumen y entrevistas. Elige la plataforma según lo que se te atragantó en el módulo 7, y recuerda su límite: enseñan a consultar, no a diseñar. Los módulos 4, 5 y 8 de este curso no tienen plataforma equivalente, y su equivalente es diseñar cosas y someterlas a crítica.

La tercera: cuando quieras profundidad, ve a la universidad. El material abierto del CMU Database Group y la serie «Databases» de Stanford están a un nivel que ningún curso comercial de SQL alcanza, y son la continuación natural de lo que 01-04 y 06-03 dejaron apuntado. Búscalos por su título exacto en el sitio de la institución.

Y la cuarta, la que decide si las otras tres sirven de algo: escribe tu plan y ponle entregables. Cuatro bloques de tres semanas, un recurso nombrado y una cosa construida por bloque, dos franjas fijas en el calendario y una revisión a mitad de camino para recortar sin abandonar. Sin entregables no hay plan; con entregables, en doce semanas tienes un proyecto público que vale más que cualquier certificado.

Y por última vez la advertencia que abre y cierra esta lección: cursos, precios, planes gratuitos, catálogos de certificación y contenidos cambian sin aviso, y los cursos de producto envejecen mal. Verifica siempre en la fuente oficial antes de matricularte o pagar, y ante cualquier discrepancia entre un curso y la documentación del motor, la documentación tiene razón.

Ya tienes qué leer y dónde practicar. Falta el tercer vértice: con qué. La lección 09-03 cubre las herramientas con las que se trabaja de verdad —los motores en tu máquina, los clientes, las herramientas de diseño, las migraciones, los datos de prueba, el diagnóstico y las copias de seguridad— e incluye el fichero de Docker Compose que levanta en un comando el entorno exacto del caso políglota de 08-03.