筆者は正規化などなんとなくのDB設計については知っている程度で
DB設計についてあまり知識はありませんでした。
もう少しDB設計について体系的に学びたいと思い読みました。
個人的に学べたことを書いていこうと思います。
学べたこと
達人に学ぶDB設計を通して学べたことがたくさんありました。
ネットの記事などを使って断片的に学ぶのでは得られなかったことが以下でした。
- 物理設計について
- DB冗長構成
- レプリケーション
- バックアップ・リカバリ設計について
- クラウドにおけるDBの冗長構成について
- 論理設計とパフォーマンスについて
- インデックスの設計方針
- インデックス以外のチューニング方法
- 論理設計のアンチパターン
- 気づきにくいグレーな設計の注意点と扱い方について
上記について、少しでも想像ができないのであればこの本を読む価値があると思います。
特に物理設計の話やインデックスなどのチューニング方法は
パフォーマンスの話であり、DB設計する上で考慮するべき内容だと思います。
なぜその設計にしたのか語れるように
AIが色々教えてくれる時代なのでなんとなくDB設計もできてしまうと思います。
しかし、この設計が最強みたいなものはなく、業務上の微妙な仕様の違いによって
適切なDB設計は変わることをこの本が教えてくれました。
そうした適切な判断を最終的にするのは人間であり、
なぜその設計にしたかを語れる必要があると思います。
もちろん、そうした設計は長年の経験から判断することも多いと思いますが
判断の基となるベースの知識をこの本は教えてくれていると思います。
長年ベストセラーとしてこれだけたくさんの人に読まれているのが何よりの証拠です。
様々なエンジニアがこの本を読めばDB設計の基本的なことは
網羅的に理解できると言われる理由がわかります。
むしろ、読んでいてそこまで理解しなくて良いのではないかと思うかもしれないほどです。
9章だけは「これ理解する必要あるのか？」と疑問に思いました（笑）。
AIが発達した今、なぜその設計にしたのかを
しっかり語れるようなエンジニアになっていきたいです。
達人に学ぶDB設計は難しいか？
何を難しいとするかで変わりますよね。
難しいと見えるものでも意外と紐解いていくと基本的な構造の組み合わせだったりします。
そういった意味では現役でエンジニアをやっている自分からすれば、
理解できないほど難しいものではなかったように思えます。
むしろ、疑問がたくさん出てきてAIに聞きながら深掘りしていって楽しく読ませていただきました。
エンジニアとして開発などをする上ではこれといった正解がないため、アンチパターンと呼ばれるものを理解して致命的なエラーを防ぐ方法が効果的だと思います。
そういった面では、アンチパターンから始まり、少し踏み込んだグレーな設計の話をしてくれたので、難しくも面白かったです。
特に印象に残ったところ
ヒント句を使った実行計画の指示を与えてパフォーマンスを改善する箇所です。
実行計画の指示なんかエンジニアがやることあるのか？と思いました。
DBに任せた方が良くない？と。
しかし、実際にはサービスを続けてデータが増えたことによって、
開発／検証環境と本番でデータ量が変わり、オプティマイザが
異なる実行計画を出してきて本番だけクエリがタイムアウトする
みたいなことが普通にあるらしいです。
explainを実行することで、実行計画を確認することができるみたいです。
実行計画を確認して、フルスキャン走ってるなとか想定しているインデックス使われてねーなとか思うことがあるみたいです。
この辺で計算量の話が始まり、アルゴリズム全般の話が出てくると。
データ構造やアルゴリズムが大事ということはRecursionという学習サイトをやっていたときに言われてました。
その時はピンとこなくて、大事だろうけど本当に大事なのか？と思うほどでした。
しかし、実際に実行計画からアルゴリズムの話が出てくるとなると、データ構造とアルゴリズムの話がサービスを運営していく上で大事だということが腑に落ちました。
まとめ
達人に学ぶDB設計を読んで学んだことを書いてみました。
読んでいると、当たり前に思えることが出来ていない設計が
世の中にはたくさんあるということがこの本から学べました。
アンチパターンも学ぶことによって、業務で致命的なミスを防げたり
既存のDBを見るときもアンチパターンの存在を確認することで
より良い設計に修正することが出来ます。
何より、DB設計の基礎を学んだことで業務で少しでも
自信を持って携われそうという自信が付きました。
DB設計を実務なしに完璧にできるようになることはないと思うので
こうした少しの自信をつけていくことが大切だと思います。