Unde se află de fapt schema bazei de date

Tot ce face acest serviciu se află în controlul versiunilor. Codul, cel puțin. Baza de date pe care rulează are 32 de tabele, iar 15 dintre ele nu au nicio definiție nicăieri în depozitul de cod — niciun CREATE TABLE, niciun fișier de schemă, nimic. Un dump le restaurează pe toate 32 cu structura intactă; ce nu conține depozitul este o a doua copie, independentă, a acelei structuri.

Aceste cifre provin din compararea bazei de date în funcțiune cu 736 de fișiere și 5.671.710 caractere din depozit. Nu sunt o estimare.

Cum dispare jumătate dintr-o schemă

Nu este vorba de neglijență, și tocmai de aceea merită consemnat. Fiecare pas în parte a fost rezonabil.

Tabelele create înainte să existe baza de cod actuală nu au fost consemnate niciodată, pentru că la vremea aceea pur și simplu existau. Tabelele adăugate de atunci au venit prin scripturi de migrare, iar acele scripturi se află în depozit — de acolo provin cele 17 definiții. Coloanele apărute ulterior au fost adăugate cu un ALTER TABLE de un singur rând, tastat la prompt, pentru că tastarea lui era mai rapidă decât scrierea unui script pentru o modificare care dura o secundă.

Indexurile sunt cazul cel mai rău. Un index este adăugat atunci când ceva e lent, chiar în momentul în care e lent, și rezolvă problema imediat. Nu rămâne în urmă niciun artefact, nimic de revizuit, nimic care să eșueze când este uitat. Unsprezece dintre cele treizeci și două de indexuri secundare de aici există exact din acest motiv și nu sunt consemnate nicăieri.

Tabelul care conține contoarele înseși, 166.438 de rânduri, se numără printre cele cincisprezece fără definiție în depozit.

Ce se strică de fapt

Nu mare lucru, până la un moment anume: când baza de date este restaurată dintr-un dump.

Un dump conține structura, așa că o restaurare directă este în regulă. Pericolul este orice cale care reconstruiește un tabel în loc să îl restaureze — mutarea pe altă mașină, importul unor tabele selectate, recrearea unuia dintr-un script. Datele revin, iar indexurile, pe tăcute, nu. Nimic nu eșuează. Interogările returnează răspunsurile corecte. Doar că durează mai mult, iar cauza este invizibilă, pentru că singura evidență a ceea ce era indexul este mașina care nu îl mai are.

Acesta este tipul de eșec care merită numit: un index lipsă nu produce o eroare, ci un răspuns corect mai lent. Nu există niciun test pentru asta, pentru că testele trec.

Ce facem între timp

Schema nu se află astăzi în depozit, iar aceasta este descrierea exactă a stării. Ce există este mai restrâns decât o remediere completă și acoperă cazul care chiar costă ceva:

Un dump înainte de orice operațiune distructivă, păstrat în afara directorului rădăcină web. O restaurare care a fost efectiv realizată cel puțin o dată, nu doar presupusă. Și o listă scurtă, verificată după fiecare restaurare, a indexurilor despre care se știe că există doar în baza de date în funcțiune — pentru că mașina poate fi întrebată ce indexuri are, iar răspunsul poate fi comparat cu ultima dată când a fost întrebată.

Versiunea generală se aplică la mai mult decât bazele de date. Dacă o parte a unui sistem există doar în sistemul în funcțiune, nu există o a doua copie a ei. Întrebarea care merită pusă despre orice componentă de infrastructură nu este dacă are copie de rezervă, ci ce nu ar putea fi reconstruit din depozit dacă mașina ar dispărea. Aici răspunsul este: cincisprezece tabele și unsprezece indexuri; stabilirea lui a durat o după-amiază și este o listă, nu o necunoscută.

Actualizare: septembrie 2026

La cinci zile după publicarea acestui articol, conținutul directorului de lucru a fost înregistrat printr-un commit: 26 de fișiere și 4.058 de linii, printre ele unsprezece scripturi de migrare scrise între 28 august și 1 septembrie, care până atunci existau doar pe mașina în funcțiune. Aceasta a fost jumătatea ușoară — cod care fusese scris, dar niciodată consemnat.

Măsurătoarea a fost repetată pe 1 septembrie 2026 în același fel: baza de date în funcțiune față de tot ce urmărește git.

Tabele	46	30 cu un CREATE TABLE în depozit, 16 fără
Indexuri secundare	43	32 create de cod din depozit, 11 doar în baza de date în funcțiune
Scripturi de migrare	109	în controlul versiunilor

Numărul care contează nu s-a mișcat. Pe 27 august, unsprezece indexuri secundare nu existau nicăieri altundeva decât în baza de date în funcțiune. Pe 1 septembrie sunt tot unsprezece. Între timp au fost adăugate alte unsprezece indexuri și fiecare dintre ele a venit cu un script de migrare: obiceiul s-a schimbat, datoria nu.

Cele unsprezece stau pe cinci tabele — contoarele, limbile, sursele de trimitere, lista de excluderi și jurnalul de evenimente. Toate cinci sunt anterioare bazei de cod actuale, și exact de aceea nu s-a consemnat niciodată nimic pentru ele. A scrie acum un fișier ar însemna a reconstrui, pornind de la un server în funcțiune, ce a fost tastat la un prompt cu ani în urmă.

Așadar, poziția din august rămâne valabilă. Schema nu se află nici acum în depozit, iar o restaurare care reconstruiește un tabel în loc să îl restaureze ar pierde în continuare unsprezece indexuri fără niciun cuvânt. Ce s-a schimbat este mai restrâns: tot ce a fost adăugat de atunci a lăsat un fișier în urmă.