「RDBの正しい歩き方」を読んだメモ

すごい面白い本だったので、心に残った部分をメモしておきます。

失敗から学ぶRDBの正しい歩き方 (Software Design plus)

失敗から学ぶRDBの正しい歩き方 (Software Design plus)

第2章 失われた真実

  • 履歴データを残さないことで、「後からデータを遡りたいときに事実が失われている設計をしてしまう」
  • 過去の事実は非常時に必要となる

第4章 効かないINDEX

第5章 フラグの闇

  • 「とりあえず削除フラグ」という罠
    • クエリの複雑化
    • カーディナリティの低下
  • DBには「事実」のみを保存し、テーブルに「状態」を持たせない
    • statusカラムを作らない
      • ましてや、そのステータスを1~5といった数値型にしない
    • カラムに状態を持たせると、レコード件数が増加してきた際に、アプリ処理にて詰んでしまいかねない

第6章 ソートの依存

  • エクゼキュータの評価順序を意識する
  • ORDER BY句のINDEX
    • B-tree Indexはソート済の状態で保存される
    • であるならば、Index経由でデータを取得することで、データはソート済となりOrder by句が不要となる

第7章 隠された状態

  • データに複数の意味を持たせない
    • 「意味を含んだID」をつくらない
    • IDは識別できる一意の値以上の意味を持たせない
  • 複数の目的に使われるようなテーブルを作らない
  • トリガーを使っても良い場面
    • パフォーマンス的メリット
    • アプリ側の実行が大幅に短縮できる
    • 既存のアプリの振る舞いを維持したまま、仕様を変更できる

第8章 JSONの甘い罠

  • JSONデータ型を採用してはならない場面
    • 正規化できる
    • 頻繁に更新される
    • 検索条件としてJSON内の属性が固定できない

第9章 強すぎる制約

  • 許容できる、強い制約
    • 一般的な事実の範囲に収まる、または守るべきデッドラインが明確になっているもの
      • 都道府県は47個しかない、消費税は3以上の整数である、等
  • 強すぎる制約
    • システムの仕様や、ビジネス・ルールに基づいているもの
      • 特定のドメインのメールアドレスは登録できない、等

第10章 転んだ後のバックアップ

  • 定期的なリストアテストを実施する
    • 日次で取得されるバックアップを用いて、毎日ステージング環境へ自動化処理でDBをリストアする