近々DB設計の機会があるので、一度網羅的にデータベースを理解したいと思い、「達人に学ぶDB設計 徹底指南書」を読みました。今回は読了後のまとめです。
↓Amazonにて購入できます
達人に学ぶDB設計 徹底指南書 | ミック | 工学 | Kindleストア | Amazon
読了後の感想
この本は単に知識を羅列しているわけではなく、「何故本書に書かれているような設計が必要であるのか」が開発現場で起こった実例を踏まえて書かれていたりするので、大変説得力があります。 内容的には中級者向けというレビューが多く、実際読んでみてもある程度データベースを触ったりSQLを書いたことがある程度の知識は必要と感じました。
読んでみて良かったこと
私の中でざっくりとした理解であった「正規化」、「インデックス」について丁寧に記述されていたのが個人的には大満足でした。
正規化は言語化してまとめるのが難しい概念ですが、それを平易な文章で例を交えて説明されているので読むのも苦になりませんでした。「あ～、こういうカラムが並んだ時ってよくテーブル分けたりするよなぁ～」といった経験と勘でやっていたことが文章化されています。
B-treeインデックスの章では、WHERE句内で否定形やORを使ったり、インデックス列へ演算をすると意味を為さない…といった仕様を初めて知りました。今まで書いてきたSQLを見直す良い機会にもなり、知らず知らずのうちに低パフォーマンスなSQLを書いてたことも自覚しました…😑リファクタリングしたくなってきた…。
読んでみてさらに悩んだこと
本書ではプライマリキー(pk)には原則的にナチュラルキーであることを強く奨める記述があるのですが、この点だけはケースバイケースで、サロゲートキーを使うメリットがデメリットを上回るようならば使って問題ないのではないかというのが私個人の見解です。
特に
- テーブル結合時のキーが少なくて済む
- SQLの記述ミスの確率が下がる
- テーブル同士の依存関係が薄くなり、変更の影響を受けにくくなる
というメリットは大きいと感じています。 Webのアジャイル開発では仕様変更も多いので影響の少なさは魅力です。
しかし様々なブログ記事などを検索してみるとこの問題については意見が割れており、宗教戦争のような様相を呈しているようですね…。 SIer系ではナチュラルキー、Web系ではサロゲートキーをpkに用いるといった傾向があったりするようです。Web系ではRailsのようにフレームワーク側がサロゲートキーを強制する仕様だったりすることも傾向を作る一因になったのかもしれません。
優劣を付けるようなものではなく、要件に合わせて選択をするのがベターといったところでしょうか。
あとがき
同じ著者さんが出版されている「達人に学ぶSQL徹底指南書」も気になったので、早速Kindle版を購入しちゃいました。また空き時間にちびちび読んでいこうと思います！
