正規化が問題を解決する
前の記事『システムは何からできているか』で挙げたデータの問題について、解決に必要となる技術は何でしょうか？
そのひとつはデータベースの「正規化」です。
さらに言えば、「正しく」正規化できてしまえば問題の大半は解決します。
しかしながら正規化についてこのように述べると、次のような反論をされることがあります。
- 正規化したら遅くなる。
- 性能のためにあえて非正規化が必要。
- 正規化するとSQLが複雑になる。
- 第一から第五正規形にボイスコッド正規形などもあるが、どこまで正規化すればよいのか。
- 正規化したデータは人間にとって読みづらい。
- 正規化したがうまくいかなかった。
先に結論として、次のことを強く主張します。
- 正規形は遅くない。むしろ速い。
- 非正規形は百害あって、ごくわずかな利しかない。
- 正規形はSQLの複雑性を緩和する。
- 第三正規形までは必須。あとは必要に応じて。
- 正規形はプログラム処理に特化した形式であり、可読性とは両立できない。
- 正規化だけが設計ではない。主キーやライフサイクルなどの設計も必要。
以上のことはなかなか理解されないことが多いため、これを理解してもらいたいというのが、このブログの最大の目標となります。
「そんなことは当たり前」と思う方は読み飛ばしてもらっても大丈夫です。
「そんなはずはない」と思われる方は、ぜひ最後まで読んでいただけると嬉しいです。
正規化にまつわる誤解
さて、この状況は次に挙げる誤解が影響していると思われます。
- 正規化するとJOINでI/Oが多くなるため遅い
- 非正規化すればI/Oが減るので速い
- 非正規化した方がSQLがシンプルになる
上記は昔から語り継がれており、書籍や技術ブログなどの解説にも登場します。最近流行りのAIにも非正規化の目的について聞いてみましたが、似たような答えが返ってきました。
では、これが本当に正しいか検証した人はいるのでしょうか？
正しいと思う方は、次の問いについて考えてみてください。
- JOINが遅いという話は、どれくらい遅いのか？
- 非正規形が速いという話は、どれくらい速いのか？
- 非正規形テーブルに対するSQLは本当にシンプルなのか？
具体的に答えられる方は、あまりいないのではないでしょうか？
実際に検証された事例を探してみましたが、非正規形が速いという結論を見つけることはできませんでした。
一方で、どうしてそのような結論に至ったのかは想像できます。
非正規化すると、必要な情報が1レコードの中に揃っている
↓
1レコードに情報が揃っているので、1回のI/Oで必要な情報が全部取れる（JOINがない）
↓
1テーブルだけが対象なのでSQLの記述が少なく済む（シンプル）
一見正しそうに見えますが、データベースで発生するI/Oに対する理解が間違っています。また、非正規化を行うことで発生する副作用についても考えられていません。
具体的にどう間違っているのかは長くなりますので、次回の記事で説明したいと思います。
また、さらに続けて実際の性能測定と検証も行っていきますので、ご期待下さい。
(まだ評価がありません)
