Írjon a támogatásnak

E-mailben válaszolunk, általában két napon belül.

A Google reCAPTCHA visszaélés elleni védelemként ellenőrzi ezt a beküldést; ennek során adatok jutnak el a Google-hoz. A szkript csak az űrlap megnyitásakor töltődik be.

← Összes bejegyzés

Három oszlop a Stats4U 2 idejéből

Az itteni fő számlálótáblának 166 436 sora van, és jó néhány oszlopa, amely fontosnak látszik. Közülük három: lastdomain, firstdomain és userdomain. Ezekben van adat:

lastdomain15 525 sorban nem üres
firstdomain15 457 sorban nem üres
userdomain2 982 sorban nem üres
számlálósorok: 166 436lastdomain15 525firstdomain15 457userdomain2 982166 436

Semmi sem írja őket. A kódbázisban egyetlen utasítás sem állítja be egyiket sem a három közül. Az értékek a szolgáltatás előző generációjából származnak, abban az állapotban fagytak meg, amelyben annak leállásakor voltak, és minden azóta létrehozott sorban üresek.

Miért nehezebb értelmezni egy félig kitöltött oszlopot, mint egy üreset

Egy teljesen üres oszlop nyilvánvalóan halott. Senki nem épít rá, senki nem készít belőle kimutatást, senki nem tölt el egy délutánt azon töprengve, mit jelent.

Egy oszlop, amely a sorok 9%-ában ki van töltve, csapda. Olyan mezőnek látszik, amely néha ki van töltve, néha nem — ami egy oszlopnál teljesen hétköznapi dolog. Aki rátalál, észszerűen arra következtet, hogy van egy szabály, amely eldönti, mikor kap értéket, és elkezdi keresni ezt a szabályt. Nincs ilyen.

Az elavult értékek ráadásul nem alvó sorokban lapulnak, ahol nem árthatnának. Azok közül a sorok közül, amelyekben ki van töltve ez: lastdomain, 1 613 olyan számlálóhoz tartozik, amely idén is frissült még. Egy élő számláló, amelyhez egy évtizede rögzített domain tartozik, pontosan úgy néz ki, mint egy élő számláló aktuális domainnel.

Ami még rosszabb, az adatok hihetőek. Ezek domainek, számlálók domainjeinek látszanak, és egy rájuk épülő join lekérdezés sorokat ad vissza. Egy olyan webről szóló kérdésre felelne, amely már továbblépett.

Hogyan lehet gyorsan eldönteni

Az írásokra kell greppelni, nem a névre. Egy oszlopnév szerepel a SELECT listákban, sémadumpokban, régi migrációkban, megjegyzésekben — ezek egyike sem bizonyít semmit. Az dönt, hogy említi-e bármelyik INSERT vagy UPDATE utasítás. Ez a keresés egy percig tart, és olyan módon perdöntő, ahogyan a kód körüli olvasgatás nem.

A második ellenőrzés maga az adat: ha a legfrissebb, értéket tartalmazó sor évekkel ezelőtti, akkor az oszlop kövület, bármit mutasson is a kód.

Miért vannak még mindig ott

Egy oszlop eldobása olcsó, de nem ingyenes. Ezeknek a soroknak mindegyike valakinek a számlálójához tartozik, némelyik 2006 óta folyamatosan működik, és egy ilyen táblán végzett sémamódosítás előtt a biztonságos lépés egy olyan mentés, amelyet egyszer ténylegesen vissza is állítottak, nem csak elkészítettek. Ezt a gyakorlatot azóta el is végeztük. Amíg az eldobásuk önmagáért nem éri meg, három nem használt oszlop egy pillanatnyi zavaron kívül semmibe sem kerül, és az alább leírt megjegyzés még azt is megszünteti.

Ezért inkább dokumentáltuk őket. Nincs kézenfekvő hely ennek a megjegyzésnek — ennek az adatbázisnak a sémája csak a futó adatbázisban létezik, a kódtárban egyetlen fájlban sem — ezért oda került, ahol valaki ténylegesen belebotlik: abba az osztályba, amely egy számlálósort beolvas, pontosan oda, ahol az oszlopok elhaladnak. Egy olyan fájlban lévő megjegyzés, amelyet senki nem nyit meg, nem dokumentáció. Csak akkor lesz a csapdából lábjegyzet, ha az útba esik.

Hirdetés