Hol él valójában az adatbázisséma

Mindaz, amit ez a szolgáltatás csinál, verziókezelés alatt áll. A kód legalábbis. Az adatbázis, amelyen fut, 32 táblából áll, és közülük 15-nek sehol sincs definíciója a tárolóban (repository) — nincs CREATE TABLE, nincs sémafájl, semmi. Egy dump mind a 32 táblát a szerkezetükkel együtt visszaállítja; ami a tárolóban nincs meg, az ennek a szerkezetnek egy második, független példánya.

Ezek a számok az élő adatbázis és a tároló 736 fájljának, 5 671 710 karakterének összevetéséből származnak. Nem becslések.

Hogyan tűnik el egy séma fele

Nem hanyagság, és éppen ezért érdemes leírni. Minden egyes lépés észszerű volt.

A jelenlegi kódbázis előtt létrehozott táblákat soha nem írták le, mert akkoriban egyszerűen ott voltak. Az azóta hozzáadott táblák migrációs szkripteken keresztül érkeztek, és ezek a szkriptek benne vannak a tárolóban — innen származik a 17 definíció. A később hozzáadott oszlopok egy parancssorba begépelt egysoros ALTER TABLE utasítással kerültek be, mert gyorsabb volt begépelni, mint szkriptet írni egy egy másodpercig tartó változtatáshoz.

Az indexek a legrosszabb eset. Egy indexet akkor adnak hozzá, amikor valami lassú, abban a pillanatban, amikor lassú, és az azonnal megoldja a problémát. Nem marad utána semmilyen nyom, semmi, amit át lehetne nézni, semmi, ami elbukna, ha elfelejtik. Az itteni harminckét másodlagos index közül tizenegy pontosan ezért létezik, és sehol sincs rögzítve.

A magukat a számlálókat tartalmazó tábla a maga 166 438 sorával azon tizenöt közé tartozik, amelyeknek nincs definíciója a tárolóban.

Mi romlik el valójában

Nem sok, egészen egy konkrét pillanatig: amikor az adatbázist egy dumpból állítják vissza.

A dump magával viszi a szerkezetet, így egy egyszerű visszaállítás rendben van. A veszélyt minden olyan út jelenti, amely újraépít egy táblát ahelyett, hogy visszaállítaná — átköltözés másik gépre, kiválasztott táblák importálása, egy tábla újralétrehozása szkriptből. Az adatok visszajönnek, az indexek pedig csendben nem. Semmi sem ad hibát. A lekérdezések helyes választ adnak. Csak tovább tartanak, és az ok láthatatlan, mert az index egyetlen nyilvántartása az a gép, amelyen már nincs meg.

Ezt a hibamódot érdemes nevén nevezni: egy hiányzó index nem hibát okoz, hanem lassabban érkező helyes választ. Nincs rá teszt, mert a tesztek átmennek.

Mit teszünk addig is

A séma ma nincs a tárolóban, és ez az állapot pontos leírása. Ami működik, az szűkebb egy teljes megoldásnál, de azt az esetet fedi le, amely ténylegesen kárt okozna:

Egy dump minden romboló művelet előtt, a webgyökéren kívül tárolva. Egy visszaállítás, amelyet legalább egyszer ténylegesen elvégeztünk, ahelyett, hogy csak feltételeznénk, hogy működik. És egy rövid lista azokról az indexekről, amelyekről tudjuk, hogy csak a futó adatbázisban léteznek, és amelyet minden visszaállítás után ellenőrzünk — mert a gépet meg lehet kérdezni, milyen indexei vannak, és a választ össze lehet vetni azzal, amit legutóbb mondott.

Az általános tanulság nemcsak az adatbázisokra érvényes. Ha egy rendszer egy része csak a futó rendszerben létezik, nincs belőle második példány. Bármely infrastruktúra-elemnél nem az a kérdés, hogy van-e róla biztonsági mentés, hanem az, hogy mit nem lehetne újraépíteni a tárolóból, ha a gép eltűnne. Itt a válasz tizenöt tábla és tizenegy index, egy délután alatt derült ki, és ez egy lista, nem egy ismeretlen.

Frissítés – 2026. szeptember

Öt nappal a bejegyzés megjelenése után a munkakönyvtár bekerült a verziókezelésbe: 26 fájl és 4 058 sor, köztük tizenegy migrációs szkript, amelyeket augusztus 28. és szeptember 1. között írtunk, és addig csak a futó gépen léteztek. Ez volt a könnyebbik fele — olyan kód, amelyet megírtunk, de soha nem rögzítettünk.

A mérést 2026. szeptember 1-jén ugyanígy megismételtük: az élő adatbázist összevetettük mindazzal, amit a git nyilvántart.

Táblák	46	30 esetében van CREATE TABLE utasítás a tárolóban, 16 esetében nincs
Másodlagos indexek	43	32-t a tárolóban lévő kód hoz létre, 11 csak a futó adatbázisban létezik
Migrációs szkriptek	109	verziókezelés alatt

A lényeges szám nem mozdult. Augusztus 27-én tizenegy másodlagos index létezett kizárólag a futó adatbázisban. Szeptember 1-jén még mindig tizenegy. Közben tizenegy további index került be, és mindegyik migrációs szkripttel érkezett: a szokás megváltozott, az adósság nem.

A tizenegy index öt táblán ül — a számlálókén, a nyelvekén, a hivatkozó oldalakén, a kizárási listáén és az eseménynaplóén. Mind az öt régebbi a jelenlegi kódbázisnál, és éppen ezért nem írtak le róluk soha semmit. Ha most fájlt írnánk, az azt jelentené, hogy egy futó szerverből rekonstruáljuk, amit évekkel ezelőtt begépeltek egy parancssorba.

Így az augusztusi álláspont érvényben marad. A séma még mindig nincs a tárolóban, és egy olyan visszaállítás, amely a táblát újraépíti ahelyett, hogy visszaállítaná, még mindig szó nélkül elhagyna tizenegy indexet. Ami változott, az szűkebb: minden, amit azóta hozzáadtunk, fájlt hagyott maga után.