正規化されてないテーブルには意味があるはず！

アプリケーション開発するにあたって、データベースの利用は必須になる。

特に、リレーショナルデータベースの利用頻度は半端ない。

使ってないアプリはない！と言ってもいいほど。

リレーショナルデータベースを利用するにあたり、正規化することが正義であり、絶対である！というのが、エンジニア界隈では常識として扱われる。

正規化すると、かぶったデータを管理しなくてよくなるため、メンテナンス性が良い。

僕は、基本はこの方針に賛成ではあるのだが、絶対ではないよな！と考えてる。

正規化することのデメリットはテーブル数の増加により、selectでデータ取得する際、joinするテーブル数が増える。

大量データを扱う場合、こいつが速度のボトルネックになることがたまにある。

アプリケーションを利用する最大の目的は効率化であるはず。

例えば、家計簿の合計支出を計算するのには、電卓叩くよりもアプリ使った方が早いから使う。

何にどのくらい使っているのかを把握して、来月の節約ポイントを把握したりするために使うはずだ。

一瞬で、グラフや計算をしてくれるから、ノートに家計簿をつけていくよりも早くて効率化されている。

このグラフ化や計算がノートでやるよりも遅かったら、アプリを使う理由はなくなる。どっちでやっても同じ時間だからだ。

これを考えると、速度は正義！という理論が出来上がる。

エンジニアの常識なんてどーでもよくなるわけである。

この場合、正規化を捨てて、非正規化に踏み切る。出来るだけjoin数を減らすのだ。

Index貼って早くすることもできるけれど、それでもデータ量次第では厳しいケースは、こっから改善していく。

これで速度改善できるなら、それはそれでいいと考える。だって、エンジニアのためにアプリ作ってるわけじゃないからね。

他のパターンも考えられる。

いきなり仕様変わって、正規化し直してたら納期に間に合わないから仕方なくやっているパターン。

まぁ、これもなんとなくわかるが、納期の交渉したのか？ってのが最初に思い浮かぶ。

そして、こいつが厄介で、担当者が辞めたりした場合、単なる謎になる。

こうなった経緯を書いたドキュメントやコメントがあればいいのだが、だいたいそんなものは存在しない。

つまり、迷宮入りだ。

もし、納期的な問題だった場合、そんなものはその当時に担当してなかったらわからない個人に依存する出来事。

後任にはわからないのだ。

本当は意味のある構成なのではないか？

引き継いだソースコードが汚かったりすると、まさか、こいつは、正規化という概念を知らない奴が作ったのか？

それとも、使わなくなったカラムなのか？

ということを、ひたすら考えることになり、頭が痛くなる。

理由がわかるように、データベースのバージョン管理も導入してほしいものだ。