『SQLアンチパターン』を読んだ②「II部 データベース物理設計のアンチパターン」

前回：

hirapi.hatenablog.jp

Ⅱ部は4章だけなので軽め

メッセージ

（だと思ったこと）

• DBMS・データベースエンジンの仕様に詳しくあれ
• 思考停止で倣うな

ぐうの音も出ない

各章

9. ラウンディングエラー(丸め誤差)

• たしかに1社目（広告）で小数値いれるときNUMERICだった

10. サーティワンフレーバー(31 のフレーバー)

• カラムに入る値を特定の値に限定したいケース、よくありそう
  • Railsはenumがんばってくれるけど、アプリケーションコードでenumの値を変更（削除）すると過去のレコードの取得がエラーになるという罠がある（と聞いた）
• 解決策：入れられる値をレコードとして持つテーブルを作るようにする
  • メタデータにデータを混入させるな事例だった
  • そしたらCHECK制約はカラムの関係性だけにしぼるべきなのか？
    • 終了日は開始日より後ですよ、とか

11. ファントムファイル(幻のファイル)

• 今まで当然のようにS3にファイル置いてパス名をカラムに入れていた
• バックアップとかロールバックとか考えたこと無かった……
  • 本当にBLOB型に入れるかは別として、本文にもあったように検討することが大事

12. インデックスショットガン(闇雲インデックス)

• 雰囲気EXPLAINしかしてなかった 😢
• ドキュメント読むべしとのことだったのでMySQLに挑戦してみたけどさっぱり
  • 英語のほうがわかりやすいかもしれない
  • 使う時が来たら読む……
• 実は遅かったのはアプリケーション、という事案たまに見た気がする
• カバリングインデックス、活用したことない
  • 使う場合（= 検索条件には使わないが取得対象となるカラムを複合インデックスに入れる）と使わない場合（= 検索条件に使うカラムだけにインデックスを貼る）のSELECT・INSERT・UPDATE・DELETEの所要時間を測定してみると自信を持って使えるのかな