Waar het databaseschema werkelijk woont

Alles wat deze dienst doet, staat in versiebeheer. De code althans. De database waarop hij draait telt 32 tabellen, en 15 daarvan hebben nergens in de repository een definitie — geen CREATE TABLE, geen schemabestand, niets. Een dump zet alle 32 met hun structuur intact terug; wat de repository niet bevat, is een tweede, onafhankelijke kopie van die structuur.

Die getallen komen uit een vergelijking van de levende database met 736 bestanden en 5.671.710 tekens repository. Het zijn geen schattingen.

Hoe een half schema zoekraakt

Het is geen slordigheid, en juist dat maakt het het opschrijven waard. Elke afzonderlijke stap was redelijk.

Tabellen die zijn aangemaakt voordat de huidige code bestond, zijn nooit opgeschreven, want destijds waren ze er eenvoudigweg. Tabellen die sindsdien zijn bijgekomen, kwamen via migratiescripts, en die scripts staan in de repository — daar komen de 17 definities vandaan. Kolommen die later zijn toegevoegd, zijn toegevoegd met een ALTER TABLE van één regel die aan een prompt is getypt, want typen ging sneller dan een script schrijven voor een wijziging die een seconde duurde.

Indexen zijn het ergste geval. Een index wordt toegevoegd wanneer iets traag is, op het moment dat het traag is, en hij lost het probleem meteen op. Er blijft geen artefact achter, er is niets om na te kijken, er is niets dat zakt wanneer hij vergeten wordt. Elf van de tweeëndertig secundaire indexen hier bestaan om precies die reden en zijn nergens vastgelegd.

De tabel die de tellers zelf bevat, 166.438 regels daarvan, hoort bij de vijftien zonder definitie in de repository.

Wat er werkelijk kapotgaat

Niet veel, tot één bepaald moment: wanneer de database uit een dump wordt teruggezet.

Een dump draagt de structuur mee, dus een rechttoe rechtaan terugzetten is prima. Het gevaar zit in elk pad dat een tabel opnieuw opbouwt in plaats van hem terug te zetten — verhuizen naar een andere machine, geselecteerde tabellen importeren, er een uit een script opnieuw aanmaken. De gegevens komen terug en de indexen geruisloos niet. Er gaat niets mis. Bevragingen geven de juiste antwoorden. Ze duren alleen langer, en de oorzaak is onzichtbaar, want het enige verslag van wat de index was, is de machine die hem niet meer heeft.

Dat is de manier van mislukken die een naam verdient: een ontbrekende index levert geen fout op, hij levert een traag juist antwoord op. Er is geen test voor, want de tests komen erdoor.

Wat we er intussen aan doen

Het schema staat vandaag niet in de repository, en dat is de nauwkeurige beschrijving van de toestand. Wat er wel is, is smaller dan een volledige oplossing, en het dekt het geval dat werkelijk iets kost:

Een dump vóór alles wat vernietigt, bewaard buiten de webmap. Een terugzetting die ook werkelijk minstens één keer is uitgevoerd in plaats van aangenomen. En een korte lijst, na elke terugzetting nagekeken, van de indexen waarvan bekend is dat ze alleen in de draaiende database bestaan — want de machine is te vragen welke indexen ze heeft, en het antwoord is te vergelijken met de vorige keer dat het gevraagd werd.

De algemene versie geldt voor meer dan databases. Bestaat een deel van een systeem alleen in het draaiende systeem, dan is er geen tweede kopie van. De vraag die de moeite waard is bij elk stuk infrastructuur, is niet of er een reservekopie van is, maar wat er niet uit de repository opnieuw te bouwen zou zijn als de machine verdween. Hier is het antwoord vijftien tabellen en elf indexen, het kostte een middag om vast te stellen, en het is een lijst in plaats van een onbekende.

Aanvulling: september 2026

Vijf dagen nadat dit bericht online kwam, is de werkmap gecommit: 26 bestanden en 4.058 regels, waaronder elf migratiescripts die tussen 28 augustus en 1 september geschreven zijn en tot dan alleen op de draaiende machine bestonden. Dat was de makkelijke helft — code die wel geschreven maar nooit vastgelegd was.

De meting is op 1 september 2026 op dezelfde manier herhaald: de levende database tegen alles wat git bijhoudt.

Tabellen	46	30 met een CREATE TABLE in de repository, 16 zonder
Secundaire indexen	43	32 door code in de repository aangemaakt, 11 alleen in de draaiende database
Migratiescripts	109	in versiebeheer

Het getal dat ertoe doet, is niet bewogen. Op 27 augustus bestonden elf secundaire indexen nergens dan in de draaiende database. Op 1 september zijn het er nog steeds elf. Er zijn er in de tussentijd elf bijgekomen, en elk daarvan kwam met een migratiescript aan: de gewoonte veranderde, de schuld niet.

De elf zitten op vijf tabellen — de tellers, de talen, de verwijzers, de uitsluitingslijst en het gebeurtenislogboek. Alle vijf dateren van vóór de huidige code, en juist daarom is er voor hen nooit iets opgeschreven. Nu een bestand schrijven zou betekenen dat er vanaf een draaiende server gereconstrueerd wordt wat jaren geleden aan een prompt is getypt.

Het standpunt van augustus blijft dus staan. Het schema staat nog steeds niet in de repository, en een terugzetting die een tabel opnieuw opbouwt in plaats van hem terug te zetten, zou nog steeds elf indexen zonder een woord laten vallen. Wat er veranderd is, is smaller: alles wat sindsdien is bijgekomen, heeft een bestand achtergelaten.