Dónde vive realmente el esquema de la base
Sobre el contenido y su revisión
En este artículo
Todo lo que hace este servicio está en control de versiones. El código, al menos. La base de datos sobre la que corre son 32 tablas, y 15 de ellas no tienen definición en ninguna parte del repositorio — ningún CREATE TABLE, ningún archivo de esquema, nada. Una copia restaura las 32 con su forma intacta; lo que el repositorio no guarda es una segunda copia independiente de esa forma.
Estas cifras salen de comparar la base en marcha con 736 archivos y 5.671.710 caracteres de repositorio. No son una estimación.
Cómo se pierde medio esquema
No es descuido, y eso es lo que lo hace digno de escribirse. Cada paso concreto fue razonable.
Las tablas creadas antes del código actual nunca se escribieron, porque entonces sencillamente estaban. Las tablas añadidas después llegaron por scripts de migración, y esos sí están en el repositorio — de ahí salen las 17 definiciones. Las columnas añadidas más tarde llegaron con un ALTER TABLE de una línea escrito en una consola, porque escribirlo era más rápido que redactar un script para un cambio que dura un segundo.
Los índices son el peor caso. Un índice se añade cuando algo va lento, en el momento en que va lento, y lo arregla al instante. No queda ningún artefacto detrás, nada que revisar, nada que falle si se olvida. Once de los treinta y dos índices secundarios de aquí existen exactamente por eso y no están registrados en ninguna parte.
La tabla donde están los contadores mismos, 166.438 filas de ellos, es una de las quince sin definición en el repositorio.
Qué se rompe de verdad
No mucho, hasta un momento concreto: cuando la base se restaura desde un volcado.
Un volcado lleva la estructura, así que una restauración directa va bien. El peligro es cualquier camino que reconstruya una tabla en vez de restaurarla — mudarse a otra máquina, importar tablas sueltas, recrear una desde un script. Los datos vuelven y los índices calladamente no. Nada falla. Las consultas devuelven las respuestas correctas. Solo tardan más, y la causa es invisible, porque el único registro de lo que era el índice está en la máquina que ya no lo tiene.
Ese es el fallo que conviene nombrar: un índice que falta no produce un error, produce una respuesta correcta más lenta. No hay prueba para eso, porque las pruebas pasan.
Qué hacemos mientras tanto
El esquema hoy no está en el repositorio, y esa es la descripción exacta del estado. Lo que hay es más estrecho que un arreglo completo y cubre el caso que de verdad cuesta algo:
Un volcado antes de cualquier cosa destructiva, guardado fuera del directorio web. Una restauración realizada de verdad al menos una vez, en lugar de supuesta. Y una lista corta, comprobada tras cada restauración, de los índices que se sabe que existen solo en la base en marcha — porque a la máquina se le puede preguntar qué índices tiene, y la respuesta se puede comparar con la de la vez anterior.
La versión general vale para más que las bases de datos. Si una parte del sistema existe solo en el sistema en marcha, no hay una segunda copia de ella. La pregunta que merece la pena hacerse sobre cualquier pieza de infraestructura no es si está respaldada, sino qué no podría reconstruirse desde el repositorio si la máquina desapareciera. Aquí la respuesta es quince tablas y once índices, establecerlo costó una tarde, y es una lista en vez de una incógnita.
Actualización: septiembre de 2026
Cinco días después de esta entrada, el directorio de trabajo se confirmó en el repositorio: 26 archivos y 4058 líneas, entre ellas once guiones de migración escritos entre el 28 de agosto y el 1 de septiembre que hasta entonces solo existían en la máquina en marcha. Esa era la mitad fácil — código escrito pero nunca registrado.
El 1 de septiembre de 2026 se repitió la medición del mismo modo: la base de datos viva frente a todo lo que git conoce.
| Tablas | 46 | 30 con CREATE TABLE en el repositorio, 16 sin ninguno |
| Índices secundarios | 43 | 32 creados por código del repositorio, 11 solo en la base de datos viva |
| Guiones de migración | 109 | bajo control de versiones |
La cifra que importa no se movió. El 27 de agosto había once índices secundarios que no existían en ningún sitio salvo en la base de datos viva. El 1 de septiembre siguen siendo once. Entre medias se añadieron once índices más, y cada uno llegó con un guion de migración: cambió la costumbre, no la deuda.
Los once están sobre cinco tablas — los contadores, los idiomas, los referentes, la lista de exclusión y el registro de sucesos. Las cinco son anteriores al código actual, y por eso mismo nunca se anotó nada sobre ellas. Escribir ahora un archivo significaría reconstruir desde un servidor en marcha lo que se tecleó hace años en una consola.
La posición de agosto sigue en pie. El esquema continúa fuera del repositorio, y una restauración que reconstruya una tabla en vez de devolverla seguiría perdiendo once índices sin decir nada. Lo que cambió es menor: todo lo añadido desde entonces ha dejado un archivo.