データベース設計時の正規化について忘れがちだけど大事なこと
これはDB設計ポエムです。
以下読むならポエムと割り切って斜め読み推奨です。
自分はこれまでDB設計を多少は経験してきました。
他人の設計を引き継いで追加設計:8割
新規に自分で設計:2割
というような割合で。
他人の設計にはほれぼれするようなものもあったけど、ほとんどは
「このクソ塊をどうしろというのだ…。」と嘆きながら引き継ぐという事態に陥っていました。
多分自分のDB設計を引き継いだ人も僕の設計を"f**k!"とか罵っていることでしょう。*1
で、そんなアンチパターンにまみれた仕事をこなす中で、これは気をつけたほうが良いなと気付いたこと。
よくあるDB設計に関する問題というか事前に共有しておくとよい前提を幾つか。
正規化はしろ！
最低限、第三正規形になっている必要がある。これは絶対！
ここが崩れていることも多いので本当に萎えるのだけどここは本当に出発点にしてボーダーラインだと思いますよマジで。
正規化崩しするなら理由・目的を必ず残す
ボイスコッド正規形から第三正規形へとパフォーマンス要件などのために正規化崩しすること*2とか稀によくあると思います。
でも、それには必ず厳密な正規化をしていない理由・目的の文書化とセットで残す。これも絶対！
でないと、DBのバージョンアップや他テーブルの変更で意味なくなった正規化崩しとかが無駄に残ります*3。
元々は色々理由があって、妥当なバランスだったものが「それって単に設計がクソなだけですよね」って感じに負債化してしまったりします。
正規化崩しするならKVSの利用を検討する
だいたい今の時代、正規化を崩してまでパフォーマンス要件をあげようとという場合、KVSを利用したほうがよほど効果が高い場合がある。
経緯をどうやって残すか？
DB定義書が良いと思います。
もっと具体的に言うとDB定義書の各テーブルの定義を書く所に"備考"的な欄を用意してそこに書く。
そうすれば、設計変更する際には必ず編集するし目にとまるはず。
というのをふと思い出したので書いてみました。
なんというか、同じ地雷を踏まないための覚書みたいなポエムでした。（おわり）
