読書感想文@SQLアンチパターン
はじめに
こちらの本の感想を書いていきます
これっておすすめ？
個人的には、参照本としておすすめです。
タイトルにあるようにパターン集としての側面が強いので、体系的にSQLを学びたい方にはおすすめできません。
- 「SQLはだいたいわかるけど、なんか強みを活かしきれてない気がする」
- 「実装をしていて『こういうときどうしたらいいの？』と思う機会が増えてきた」
という方にはピッタリだと思います。
SQLを書く上での引き出しを広げ、そして書いたらいけないコードをパターン的に学ぶことができます。
個人的に学びになった3つのこと
今回はこの本に則って、"学びになった3つのパターン"を書きたいと思います。
ナイーブツリー (2章)
一つ目は自分の中で新たな解決策を与えてもらった章になります。
ナイーブツリーは「素朴な木」ともいい、コメント機能を作るときに起こりがちなアンチパターンになります。
以下のようにリプが続くコメント機能を作るとき、どのようなモデリングをしますか？
たとえば、こんな感じのモデリングがイメージつくかもしれません。
これこそがアンチパターンになります。以下のようなデメリットがあります。
- クエリ実行するときに子→孫→ひ孫を取得するのがめんどくさい
- ノードを消したときに、そのサブツリー全体を削除するのがめんどくさい
取得する時と、削除する時に1クエリ/コマンドでできません。
それがネックになるのでアンチパターンとなります。
ここで提示されている解決策は以下の3つでした。
- 経路列挙: 経路をカラムに保存するやり方(ex "1/4/5"を保存)
- 入れ子集合: 子孫の情報をカラムに保存するやり方(説明むずい、それがネック)
- 閉包テーブル: 別テーブルで関係性を管理するやり方
3つとも学びになりました。特に僕が実践でやるなら3の閉包テーブルかなと思いました。
理解が難しくなく、またテーブル構造的にも綺麗な感じがしまして。
具体的な説明は省きますが、この方法を知れたことは良かったです。
インデックスショットガン (12章)
こちらは、INDEXの貼り方についての指標を学べました。
ここで言っているインデックスショットガンはその名の通り、「何も考えずINDEXを貼りまくる」です。
さすがにそこまではしないものの、「なんか検索対象になりそうで、数が多そう」なものに貼るくらいのイメージしかありませんでした。
ここで紹介していたのは、「MENTOR」というINDEXを貼る上でのチェックリストです
この記事でよく紹介していただいたいるのでよくみてみてください
まぁけど↑でも言っている通り、この本の方が全然詳しいのでみてみてください。
簡単にいうと
- Measure(測定)
- そのクエリに時間がかかっているのか計測します
- Explain(解析)
- なんでそのクエリに時間がかかっているのかを解析します
- Nominate(指名)
- 解析した結果INDEXを貼るべき場所を指定します
- Test(テスト)
- INDEXを貼ったのち、どれほど改善されたのか検証します
- Optimize(最適化)
- INDEXはDBに保存せずに一時的にキャッシュに保存した方がいい場合もあり、それ周りの最適化してくる
- Rebuild(再構築)
- INDEXの再構築をすることで、ぐちゃぐちゃになったINDEXを綺麗にでき、パフォーマンス改善されることがあります
みたいな。
ISUCONのときに学んだことが活かせそうだなとも感じましたが、今後INDEXを貼るときは上記を意識してみます。
ディプロマティック・イミュニティ (23章)
これはアンチパターンでさえ僕自身が認識していなかったのでここに載せました。
どうやらデータベースエンジニアは特別扱いされ、エンジニアのベストプラクティスが適用されづらいらしいです。
例えば、
- Gitなどを用いてソースコードのバージョン管理を行う
- 自動テストを書き、継続的に実行する
- ドキュメント、仕様書などを書き、アプリの要件などをまとめる
などが省かれがちだそうです。そしてそれがアンチパターンと言っています。
そしてその解決策は「特別扱いはしないが、データベースエンジニアに取って最適な品質管理につとめるべき」となっています。そして、その品質保証は文書化・バージョン管理・テスティングを意識しながらやる方がいいらしいです。
- 文書化した方がいいリスト
- ERD
- テーブル定義所
- トリガー
- ストアドプロージャ
- SQLセキュリティ
- ORM
- バージョン管理した方がいいリスト
- データ定義スクリプト
- トリガーとぷローじゃ
- ブートストラップデータ(シードデータ)
- ↑で文書化したドキュメントら
- データベース管理スクリプト
- データベースがアプリケーションに提供する機能がちゃんと働くかどうかをアイソレーションテストします
- テーブル、列、ビューなどはちゃんとあるか
- 制約は効いているか
- トリガーが動くか
- ストアドプロージャが動くか
- クエリが動くか
- ブートストラップデータが存在するか
- ORMは動作するか
↑のことを意識するだけでだいぶ違うらしい、覚えておきましょう。
さいごに
個人的には、作中にある"アンチパターンの見つけ方"はとても好きでした、声を出して笑ってしまうくらいに。
ぜひみなさん読んでみてください。
Discussion