Onde vive realmente o esquema da base de dados

Tudo o que este serviço faz está em controlo de versões. O código, pelo menos. A base de dados sobre a qual corre são 32 tabelas, e 15 delas não têm definição em parte nenhuma do repositório — nenhum CREATE TABLE, nenhum ficheiro de esquema, nada. Uma cópia repõe as 32 com a sua forma intacta; o que o repositório não guarda é uma segunda cópia independente dessa forma.

Estes números vêm de comparar a base em funcionamento com 736 ficheiros e 5.671.710 caracteres de repositório. Não são uma estimativa.

Como se perde meio esquema

Não é desleixo, e é isso que o torna digno de registo. Cada passo, isolado, foi razoável.

As tabelas criadas antes do código atual nunca foram escritas, porque na altura estavam simplesmente lá. As tabelas acrescentadas desde então chegaram por scripts de migração, e esses estão no repositório — daí vêm as 17 definições. As colunas acrescentadas mais tarde chegaram com um ALTER TABLE de uma linha escrito numa consola, porque escrevê-lo era mais rápido do que redigir um script para uma mudança que demora um segundo.

Os índices são o pior caso. Um índice acrescenta-se quando alguma coisa está lenta, no momento em que está lenta, e resolve logo. Não fica atrás nenhum artefacto, nada para rever, nada que falhe se nos esquecermos. Onze dos trinta e dois índices secundários daqui existem exatamente por isso e não estão registados em lado nenhum.

A tabela onde estão os próprios contadores, 166.438 linhas deles, é uma das quinze sem definição no repositório.

O que se parte de verdade

Pouco, até um momento concreto: quando a base é reposta a partir de uma cópia.

Uma cópia leva a estrutura, por isso uma reposição direta corre bem. O perigo é qualquer caminho que reconstrua uma tabela em vez de a repor — mudar para outra máquina, importar tabelas escolhidas, recriar uma a partir de um script. Os dados voltam e os índices, caladamente, não. Nada falha. As consultas devolvem as respostas certas. Só demoram mais, e a causa é invisível, porque o único registo do que o índice era está na máquina que já não o tem.

É esta a falha que vale a pena nomear: um índice em falta não produz um erro, produz uma resposta certa mais lenta. Não há teste para isso, porque os testes passam.

O que fazemos entretanto

O esquema hoje não está no repositório, e essa é a descrição exata do estado. O que existe é mais estreito do que uma solução completa e cobre o caso que na verdade custa alguma coisa:

Uma cópia antes de qualquer coisa destrutiva, guardada fora da raiz web. Uma reposição realmente feita pelo menos uma vez, em vez de presumida. E uma lista curta, verificada depois de cada reposição, dos índices que se sabe existirem só na base em funcionamento — porque à máquina pode perguntar-se que índices tem, e a resposta pode comparar-se com a da vez anterior.

A versão geral vale para mais do que bases de dados. Se uma parte do sistema existe só no sistema em funcionamento, não há uma segunda cópia dela. A pergunta que vale a pena fazer sobre qualquer peça de infraestrutura não é se está salvaguardada, mas o que não poderia ser reconstruído a partir do repositório se a máquina desaparecesse. Aqui a resposta é quinze tabelas e onze índices, estabelecê-lo levou uma tarde, e é uma lista em vez de uma incógnita.

Atualização: setembro de 2026

Cinco dias depois deste artigo, a pasta de trabalho foi enviada para o repositório: 26 ficheiros e 4058 linhas, entre elas onze guiões de migração escritos entre 28 de agosto e 1 de setembro que até aí existiam apenas na máquina em funcionamento. Essa era a metade fácil — código escrito mas nunca registado.

A 1 de setembro de 2026 a medição foi repetida do mesmo modo: a base de dados em funcionamento contra tudo o que o git conhece.

Tabelas	46	30 com um CREATE TABLE no repositório, 16 sem nenhum
Índices secundários	43	32 criados por código do repositório, 11 só na base em funcionamento
Guiões de migração	109	sob controlo de versões

O número que interessa não se mexeu. A 27 de agosto havia onze índices secundários que não existiam em lado nenhum a não ser na base em funcionamento. A 1 de setembro continuam a ser onze. Pelo meio juntaram-se outros onze índices, e cada um chegou com um guião de migração: mudou o hábito, não a dívida.

Os onze assentam em cinco tabelas — os contadores, as línguas, os referentes, a lista de exclusão e o registo de acontecimentos. As cinco são anteriores ao código atual, e é precisamente por isso que nunca se escreveu nada sobre elas. Escrever um ficheiro agora significaria reconstruir, a partir de um servidor em funcionamento, o que foi escrito numa linha de comandos há anos.

A posição de agosto mantém-se. O esquema continua fora do repositório, e um restauro que reconstrói uma tabela em vez de a repor perderia na mesma onze índices sem uma palavra. O que mudou é menor: tudo o que se acrescentou desde então deixou um ficheiro.