達人に学ぶDB設計 徹底指南書
RDSについて整理する。
第一章 DBを制する者はシステムを制す
第二章 論理設計と物理設計
第三章 論理設計と正規化
第四章 ER図
第五章 論理設計とパフォーマンス
第六章 データベースとパフォーマンス
第七章 論理設計のバッドノウハウ
第八章 論理設計のグレーノウハウ
第九章 一歩進んだ論理設計 SQLで木構造を扱う
第一章 DBを制する者はシステムを制す
ソフトウェア開発の歴史
プロセス中心→データ中心
データより、業務処理はよく変わるため
要件定義→設計→開発→テスト→運用
プロセス中心（要件定義～テスト）
データ中心（要件定義～運用）
DDD（要件定義～運用）
データドリブン（運用）
実運用データを収集し、システムの改善や機能追加をデータに基づいて行う。
各工程で共存できるできないの相性はある
外部スキーマ→概念スキーマ→内部スキーマ
外部スキーマ：ユーザーインターフェースや入力データ（ユーザーから見えるもの）
概念スキーマ：データ同士の関係（設計書レベル）
内部スキーマ：DBのメタデータ（インデックスのデータ構造など、通常見えない情報）
第二章 論理設計と物理設計
テーブル定義→インデックス定義→ハードウェアサイジング→ストレージ冗長構成→ファイルの物理配置
サービス終了時のデータ量を見積、それに耐えうるようにする。（または計画があれば可）
ストレージ冗長構成：少なくともRAID５ 余裕があれば10 ０は絶対ダメ
バックアップ方式：フルバックアップ＋差分or 増分バックアップ が一般的
第三章 論理設計と正規化
正規化
１：１つのセルに１つの値
２・３：(部分関数or推移的関数)従属の解消（特定のカラムの値が決まれば、一意に決まるカラムが存在しない テーブル分割を行う）
第３正規化まで実施する。
メリット：更新時の不整合の防止、データの持つ意味が明確になり理解しやすい。
デメリット：結合時性能悪化する。
第四章 ER図
第五章 論理設計とパフォーマンス
例 注文の商品数のサマリカラムの追加のケース（非正規化）
検索パフォーマンスを向上させるに非正規化は有効だがリスクが大きい
更新パフォーマンスの低下
データのリアルタイム性の低下
後続の工程で設計変更すると手戻りが大きい
第六章 データベースとパフォーマンス
インデックスと統計情報
インデックスの内部構造
データ構造（キー値・ポインタをBツリー構造で持つ）
上記が整理された状態で保持（データ更新のたびにここも更新される。）
データの検索速度が上がる。
B-tree：平衡木で探索距離が均一 フルスキャンO(n),BtreeO(log n )
CRUDすべてについて性能が向上
インデックス作成場所
・データ1万以上のテーブル
・カーディナルが高い列
・SQLのWHERE・結合条件で利用される
※主キーや一意制約のカラムには不要（内部で自動で作成されている）
インデックスが効果ないもの
・インデックス列に演算したとき col_a * 1.1 > 100（col_a > 100/1.1 はOK）
・SQL関数を使用したとき SUBSTRなど
・IS NULLを利用したとき
・否定を利用したとき ＜＞
・ORを利用したとき （INはOK）
・後方一致、中間一致のLIKEを利用したとき
・暗黙の型変換を利用したとき col_a(文字列の時） = 1 ( col_a = '1'はOK)
統計情報
SQL実行時この統計情報は計算され更新される。
必ずしも良い計算結果にならないので更新を止めることも可能。
第七章 論理設計のバッドノウハウ
キーには固定長文字列のコードが望ましい
第八章 論理設計のグレーノウハウ
代理キーを利用せず、自然キーを主キーに利用するのが望ましい
第九章 一歩進んだ論理設計 SQLで木構造を扱う
SQLで木構造のデータを保存するのは難しい
例 部署情報など
解決法として隣接リストモデルなどある
