技術

SQLの3値理論でバグを出した話

思わずこんなツイートをしてしまいました。

データエンジニアの案件に参画して、バグを出してしまいました。要因は、3値理論です。DBの初歩ですね・・・

3値理論ってなんぞや

データ型がboolean型だと、通常の開発言語はTrue or Falseの2値になります。しかしSQLは、NULLがあると True/False/Nullの3値になります。

これだけ聞くと問題ないように思いますが、その判定方法がややこしいので、3値理論というちょっとかっこいい名前がついています。

問題なのは、NULLはIS NULLでしか拾えない(検知できない)ことです。

name,is_student
—-,—
鈴木,True
田中,
佐藤,False

の場合、 is_student != True でフィルーした場合、佐藤君と田中君を抽出して欲しい気がしますが、実際は佐藤君しか拾ってくれません。

これが3値理論です。

今回やらかしたこと

booleanのカラムを追加して、NULLは入らないはずなので、True or Falseの2値判定の処理を追加してしまいました。RDBでしか開発していなかったときは、カラム追加時は基本デフォルト値を入れていましたので、今回の様な乱暴な対応でも問題になることはありませんでした。

ただ今回の環境はAthena。過去データを修正することはできません。カラム追加時は、過去データはNULLにしかできません。

ということに、バグを出してから気づきました・・・

で、追加時より過去のデータを参照したたいみんぐでデータ件数を正しく出すことができずにバグに繋がるという事態になりました。

データエンジニアの仕事で辛いと思ったこと

今回、データエンジニアをしていて、容易に修正できなことが辛いと思いました。

ロジックの修正事態は簡単なんですが、一度作られたデータを修正するには、過去分すべて再計算、いわゆるバックフィルの対応が必要になります。そのこと事態の対応がそもそも大変ですし、関係各社の合意を撮るのも大変です。

開発していたときは、バグ修正してPR出して終わりみたいな感じだったのですが、それができないのが辛いです。

対応すべき作業内容はわかっているのにできないもどかしさ、この辺はインフラの仕事に近いものがあります。

まとめ

以上、今の案件でバグ出しをした反省記事でした。

今はそのバグ対応で動いているのですが、まさにマッチポンプ。しかも、工数を割いているのは自分だけじゃありません。ビジネスサイドの方も顧客説明などに追われています。本当申し訳なさでいっぱいです・・・