Три колони, останали от Stats4U 2
Основната таблица с броячите тук има 166 436 реда и множество колони, които изглеждат важни. Три от тях са lastdomain, firstdomain и userdomain. В тях има данни:
lastdomain | не е празна в 15 525 реда |
firstdomain | не е празна в 15 457 реда |
userdomain | не е празна в 2 982 реда |
Нищо не записва в тях. Никоя инструкция в кода не задава стойност на която и да е от трите. Стойностите са от предишното поколение на тази услуга, замръзнали такива, каквито са били, когато то е спряло да работи, а всеки ред, създаден оттогава, е празен.
Защо полупопълнената колона се разчита по-трудно от празната
Изцяло празната колона очевидно е мъртва. Никой не надгражда върху нея, никой не прави отчети от нея, никой не прекарва цял следобед в чудене какво означава.
Колона, попълнена в 9 % от редовете, е капан. Тя изглежда като поле, което понякога се попълва, а понякога не — нещо напълно обичайно за една колона. Всеки, който я открие, основателно заключава, че има правило, което решава кога се задава стойност, и започва да търси правилото. Такова няма.
И остарелите стойности не са скрити в неактивни редове, където не биха навредили. От редовете със стойност в lastdomain, 1 613 принадлежат на броячи, които още са се обновявали тази година. Жив брояч с домейн, записан преди десетилетие, изглежда точно като жив брояч с актуален домейн.
По-лошото е, че данните са правдоподобни. Това са домейни, изглеждат като домейните на броячи и заявка, която съединява таблици по тях, връща редове. Тя би отговорила на въпрос за един уеб, който отдавна е продължил напред.
Как да се разбере бързо
Търсете с grep записите в колоната, а не името ѝ. Името на колона се среща в SELECT списъци, в дъмпове на схемата, в стари миграции, в коментари — нищо от това не доказва каквото и да е. Решаващо е дали някоя инструкция INSERT или UPDATE я споменава. Това търсене отнема минута и дава категоричен отговор, какъвто четенето на кода наоколо не дава.
Втората проверка са самите данни: ако най-новият ред със стойност е на години, колоната е вкаменелост, независимо какво изглежда, че казва кодът.
Защо все още са там
Премахването на колона е евтино, но не е безплатно. Всеки от тези редове принадлежи на нечий брояч, някои от тях работят непрекъснато от 2006 г., а безопасната стъпка преди промяна на схемата на такава таблица е дъмп, който наистина е бил възстановен веднъж, а не просто създаден. Това упражнение вече е проведено. Докато премахването им не си заслужава само по себе си, три неизползвани колони не струват нищо освен миг объркване, а бележката, описана по-долу, премахва дори него.
Затова вместо това са документирани. Няма очевидно място за такава бележка — схемата на тази база данни съществува само в работещата база, а не в някой файл в хранилището — затова тя отиде там, където някой наистина ще се спъне в нея: в класа, който чете ред на брояч, точно където минават колоните. Бележка във файл, който никой не отваря, не е документация. Тя превръща капана в бележка под линия само ако стои на пътя.