何も書き込まない列たち

ここのカウンター本体の表には 166,436 行と、重要そうに見える列がいくつかあります。そのうち三つが lastdomain、firstdomain、userdomain です。データが入っています。

lastdomain	15,525 行で空でない
firstdomain	15,457 行で空でない
userdomain	2,982 行で空でない

何も書き込みません。コード全体のどの文も、三つのいずれも設定していません。値はこのサービスの前の世代のもので、それが動くのをやめたときの姿のまま凍りついており、以降に作られた行はすべて空です。

空の列より悪い理由

まったく空の列は明らかに死んでいます。誰もその上に組み立てず、誰もそこから報告を作らず、誰も午後を費やして意味を考えたりしません。

行の 9 % で埋まっている列は罠です。ときどき埋まり、ときどき埋まらない項目に見えます — 列としてはごく普通のあり方です。見つけた人は、いつ設定されるかを決める規則があるはずだと当然のように考え、その規則を探し始めます。ありません。

しかも古びた値は、害の及ばない眠った行に片づけられているわけでもありません。lastdomain を持つ行のうち 1,613 は、今年も更新されているカウンターのものです。十年前に記録されたドメインを持つ生きたカウンターは、現在のドメインを持つ生きたカウンターとまったく同じに見えます。

さらに悪いことに、データはもっともらしい。ドメインですし、カウンターのドメインのように見えますし、それで結合する問い合わせは行を返します。それが答えるのは、とうに先へ進んだウェブについての問いです。

手早く見分ける方法

名前ではなく書き込みを探すこと。列名は SELECT の並びにも、スキーマの書き出しにも、古い移行スクリプトにも、コメントにも現れます — そのどれも何も証明しません。決着をつけるのは、どこかの INSERT か UPDATE がそれに触れているかどうかです。その検索は一分で終わり、コードの周りを読み回るのとは違って決定的です。

二つ目の確認はデータそのものです。値を持つ最も新しい行が何年も前のものなら、コードが何を言っているように見えようと、その列は化石です。

まだ残っている理由

列を落とすのは安上がりですが、無料ではありません。これらの行はどれも誰かのカウンターのもので、中には 2006 年から途切れずに動いているものもあります。そういう表でスキーマを変える前の安全な手順は、実際に一度戻したことのあるバックアップであって、ただ作っただけのものではありません。それ自体をやる価値が出るまで、使われない三つの列は混乱以外の何も要求しません。

そこで代わりに文書化されています。その注記を置く明白な場所はありません — このデータベースのスキーマは動いているデータベースの中にしか存在せず、リポジトリのどのファイルにもないのです — だから、実際に人がつまずく場所へ置きました。カウンターの行を読むクラスの、ちょうどそれらの列が通り過ぎるところです。誰も開かないファイルの中の注記は文書ではありません。道の上にあってはじめて、罠を脚注に変えます。