La consulta que sacaba los alumnos con el teórico caducado tardaba 3,4 segundos en la autoescuela de Lugo donde Olalla Ferreiro Cendán lleva la administración. Recorría las 214.000 clases registradas enteras para contestar por 9.600 alumnos.
Una línea la dejó en 40 milisegundos, y esa línea no está en la consulta. Está en la tabla, y se paga en cada matrícula nueva que se guarda.
Nada de eso aparece en un ejercicio de normalización, porque una base de datos de prácticas tiene veinte filas y a veinte filas todo va rápido.
Qué compra un índice y qué cobra
La línea es CREATE INDEX sobre la columna de la fecha del teórico. Un índice es una segunda copia de la columna, guardada ordenada, con un puntero a la fila de la que salió. Buscar en algo ordenado permite descartar la mitad en cada paso, y por eso las 214.000 filas recorridas pasan a 1.100 leídas.
Lo que cobra se paga en el otro lado y no se ve en ninguna consulta. Cada alta y cada modificación escriben ahora dos veces, una en la fila y otra en la copia ordenada, y esa copia ocupa disco y hay que mantenerla al día. En la autoescuela sale a cuenta porque se consulta cien veces al día y se matricula veinte veces a la semana; en una tabla que se escribe a cada segundo y se lee una vez al mes, la misma línea es un impuesto.
La forma de comprobarlo no es el cronómetro. EXPLAIN dice si la consulta usó el índice o recorrió la tabla, y lo dice antes de ejecutarla, así que el mismo comando sirve para entender por qué una consulta que iba bien se estropeó al añadirle un ORDER BY.
NULL no es igual a NULL
La segunda consulta que Olalla escribió mal buscaba a los alumnos sin fecha de examen. Con la columna a NULL, ninguna comparación normal encuentra nada: NULL no es igual a NULL, así que IS NULL es la única comprobación que funciona.
NULL no significa cero ni cadena vacía. Significa que no se sabe, y por eso comparar dos desconocidos no puede dar verdadero. Esa regla se propaga: una suma con un NULL dentro da NULL, y un recuento sobre una columna con huecos cuenta menos filas de las que hay en la tabla.
De ahí sale la decisión de diseño que hay detrás, y que es la que importa: una columna que no puede faltar se declara NOT NULL en la tabla, y así el error salta al guardar, con nombre y fila, en vez de aparecer tres meses después dentro de un informe.
Un JOIN sin ON, y el todo o nada
El otro accidente clásico llega al cruzar dos tablas. Un JOIN sin condición ON cruza cada fila con cada fila, así que las 9.600 matrículas contra las 214.000 clases devuelven más de dos mil millones de filas y el servidor se queda sin memoria. No es un error de sintaxis: es una operación legítima que casi nunca es la que se quería.
La cuarta pieza es lo que pasa cuando algo se interrumpe a mitad. Cobrar una clase son dos escrituras, restar un bono y anotar la clase dada, y entre las dos puede irse la luz. Una transacción es todo o nada: se abre con BEGIN, se cierra con COMMIT, y si algo falla en medio, ROLLBACK deja la base exactamente como estaba.
Sin transacción, la autoescuela acaba con clases dadas que nadie ha pagado o con bonos gastados sin clase, y las dos cosas se descubren en el cierre del mes. El SQL es donde estas cuatro piezas se practican, y donde el plan de ejecución deja de ser un texto raro.
El DNI parece una clave primaria y es un dato personal
Aquí hay una capa que no lleva ninguna página escrita en inglés, y que en España decide el diseño de la tabla. Los datos de los alumnos están sujetos al RGPD, y eso convierte dos decisiones técnicas en decisiones legales.
La primera es la clave. Un DNI es único, no cambia casi nunca y viene ya escrito en el documento, así que parece la clave primaria perfecta. Es además un dato personal, y una clave primaria se copia en cada tabla que apunte a esa, con lo cual el DNI acaba repartido por media base de datos y por cada copia de seguridad. La clave se pone artificial, un número interno sin significado, y el DNI se queda en una sola columna de una sola tabla.
La segunda es el borrado. La costumbre del sector es no borrar nunca: una columna de baja, un valor a cierto, y la fila se queda. Marcar una fila como borrada no cumple el derecho de supresión, porque el dato sigue ahí y sigue siendo recuperable por cualquiera con acceso a la tabla. Lo que sí cumple es borrar de verdad, o dejar la fila con los campos personales vaciados cuando hay una obligación de conservar el resto, que en una autoescuela la hay para la parte contable.
Ese es el tipo de decisión que se toma en el diseño de bases de datos, antes de que exista ninguna fila, y que sale carísima de cambiar después.
El orden
Cuatro peldaños, y cada uno es invisible si empiezas por encima de él
Casi todo el mundo empieza por el tercero, porque es el que trae nombre puesto en el aula y en la oferta de empleo.
- 04La otra formaDocumentos y claves, cuando una fila fija es de verdad el envase equivocado.Sin los tres primeros, esto es una apuesta
- 03El motorQué producto, qué dialecto, y qué hace cuando se corta la luz.Suele estar elegido antes de que llegues
- 02La formaCuáles son las tablas, qué es único y qué no puede faltar.Sáltatelo y no hay índice que salve nada
- 01El lenguajePreguntar directamente, y leer el plan con el que contesta la base de datos.Sáltatelo y el mapeador es opaco
Los peldaños no son dificultad. El primero es el más fácil de aprender y el que más se aplaza, porque un mapeador escribe consultas pasables para quien empieza y deja de hacerlo justo cuando importa.
Dónde se para quien viene del módulo
El módulo de bases de datos se aprueba dibujando un diagrama entidad-relación y llevando un modelo a la tercera forma normal. El diagrama y la tercera forma normal son las dos correctas, y las dos se corrigen sobre papel. La consecuencia es una persona que normaliza bien y que no ha visto nunca una consulta tardar, porque la base de datos de clase cabía en una pantalla.
La segunda mitad del atasco es que casi todo el mundo llega por el tercer peldaño, el del motor, y con MySQL, que es lo que se instala en el aula. Eso no es un error de nadie, pero deja fuera el peldaño de abajo: quien no lee un plan de ejecución trata la base de datos como una caja que a veces va lenta.
La señal de haber salido de ahí es concreta y se nota en una reunión: ante una pantalla que tarda, la primera reacción deja de ser cambiar de servidor y pasa a ser mirar el plan de la consulta que hay debajo.
Qué abrir en 2026
SQLite es el sitio donde practicar todo lo de arriba sin instalar nada: es de dominio público, viene ya con Python y con casi cualquier sistema, y una base de datos entera es un fichero que se copia. Sustituyó a inventarse un formato propio y escribir el código que lo lee, que es lo que hacía cualquier programa pequeño antes.
PostgreSQL es el motor que conviene aprender si solo se aprende uno. Es gratis y de código abierto, y ha sustituido a MySQL como elección por defecto a lo largo de la última década, incluso en sitios donde el aula sigue enseñando MySQL. PostgreSQL y MySQL siguen los dos vivos y se parecen lo bastante como para que lo aprendido en uno valga en el otro.
EXPLAIN no es un programa aparte sino parte del motor, en todos los que valen la pena, y sustituyó a cronometrar una consulta y adivinar la causa. El fallo típico con él es leer solo el número final: lo que importa es si en el plan aparece un recorrido de tabla completo donde debería aparecer el nombre de un índice.
El orden, y por dónde entrar
El peldaño de abajo es el lenguaje, y se coge antes que ninguna herramienta que lo escriba por ti. Encima va la forma de las tablas, después el motor concreto, y arriba del todo la otra forma de guardar. Empezar por el tercero es lo normal y es lo que deja invisibles los dos de debajo.
Los motores son ese tercer peldaño puesto en orden: qué producto te van a poner delante, en qué se diferencian sus dialectos y qué hace cada uno cuando se corta la luz a mitad de una escritura. NoSQL es el cuarto, y solo se decide bien después de los tres anteriores, porque la pregunta no es cuál es más moderno sino si una fila fija es el envase equivocado para lo que hay que guardar.
Entre medias está la capa que casi todo el mundo usa sin mirar: el código que convierte objetos en filas, que es donde el mapeador escribe consultas pasables hasta justo el día en que dejan de serlo. Eso son los datos desde el código.
Lo que queda abierto es de dónde salen esas 214.000 clases y quién las escribe: casi siempre una aplicación que atiende peticiones, y eso es el desarrollo web. El coste de recorrer 214.000 filas se lee con las mismas cuentas de los fundamentos de programación, y la copia de seguridad que hay que restaurar cuando esto se rompe vive en la puesta en producción.