El esquema que solo vive en la base de datos en marcha
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. Si se perdiera el servidor, el código volvería exacto y la forma de los datos habría que reconstruirla a partir de lo que el código resulta que pide.
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
La postura honesta es que esto no está arreglado. El esquema hoy no está en el repositorio. Lo que hay es menor que un arreglo y mejor que nada:
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 está solo en el sistema en marcha, no tienes una copia de ella, tienes un rehén. La pregunta que merece la pena hacerse sobre cualquier pieza de infraestructura no es «¿está respaldada?» sino «si esta máquina desapareciera, ¿qué no podría reconstruirse desde el repositorio?». Aquí la respuesta es quince tablas y once índices, y averiguarlo costó una tarde.