すごい面白い本だったので、心に残った部分をメモしておきます。
失敗から学ぶRDBの正しい歩き方 (Software Design plus)
- 作者: 曽根壮大
- 出版社/メーカー: 技術評論社
- 発売日: 2019/03/06
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
第2章 失われた真実
- 履歴データを残さないことで、「後からデータを遡りたいときに事実が失われている設計をしてしまう」
- 過去の事実は非常時に必要となる
第4章 効かないINDEX
第5章 フラグの闇
- 「とりあえず削除フラグ」という罠
- クエリの複雑化
- カーディナリティの低下
- DBには「事実」のみを保存し、テーブルに「状態」を持たせない
- statusカラムを作らない
- ましてや、そのステータスを1~5といった数値型にしない
- カラムに状態を持たせると、レコード件数が増加してきた際に、アプリ処理にて詰んでしまいかねない
- statusカラムを作らない
第6章 ソートの依存
- エクゼキュータの評価順序を意識する
- ORDER BY句のINDEX
- B-tree Indexはソート済の状態で保存される
- であるならば、Index経由でデータを取得することで、データはソート済となりOrder by句が不要となる
第7章 隠された状態
- データに複数の意味を持たせない
- 「意味を含んだID」をつくらない
- IDは識別できる一意の値以上の意味を持たせない
- 複数の目的に使われるようなテーブルを作らない
- トリガーを使っても良い場面
- パフォーマンス的メリット
- アプリ側の実行が大幅に短縮できる
- 既存のアプリの振る舞いを維持したまま、仕様を変更できる
第8章 JSONの甘い罠
第9章 強すぎる制約
- 許容できる、強い制約
- 一般的な事実の範囲に収まる、または守るべきデッドラインが明確になっているもの
- 都道府県は47個しかない、消費税は3以上の整数である、等
- 一般的な事実の範囲に収まる、または守るべきデッドラインが明確になっているもの
- 強すぎる制約
- システムの仕様や、ビジネス・ルールに基づいているもの
- 特定のドメインのメールアドレスは登録できない、等
- システムの仕様や、ビジネス・ルールに基づいているもの
第10章 転んだ後のバックアップ
- 定期的なリストアテストを実施する
- 日次で取得されるバックアップを用いて、毎日ステージング環境へ自動化処理でDBをリストアする