失敗から学ぶRDBの正しい歩き方

第1章データベースの迷宮

現場でよくありがちな問題

memo1, memo2, ... のような何が入っているのかわからないカラム

data が、タイポで date になっていて意味が変わっている

中に入っている値の意味がわからないカラム

外部キー制約がなく、リレーションがわからないカラム

table:RDBで設定できる制約

PRIMARY KEY

NOT NULL

UNIQUE

CHECK 指定した条件の値のみが保存されていることを確定させる

DEFAULT

FOREIGN KEY

問題点

名前からテーブルの関連性や意図がわからない

リレーショナルモデルに基づいた設計をしていないと（外部キー制約張ってないとか）、便利ツールを使えない（自動的にER図生成してくれるツールとか）

保存されたデータが正しいものなのか、バグによるものなのかわからない

アンチパターンンを産まないために

命名ミスなどは初期段階ならまだ対応できる

今後を想定した命名

技術的負債: 何らかの制約により、将来に負債が残る形で対応したもの

e.g. 締め切りとか？

データベースは寿命が長い。早めのリファクタリングで技術的負債を解消

名著『データベースリファクタリング』

MySQL 8.0.16 で CHECH 制約に対応する

アンチパターンのポイント

わかりづらい設計や名前はデータベース破綻の始まり

第2章 失われた真実

第3章 アンチパターンの解説

正しくテーブル正規化しないとJOINがボトルネックになりやすいという話

Where狙いのキー、order by狙いのキー

なんかよさげな資料

第4章 効かないINDEX

43ページ誤植？

200ページ→300ページ

INDEXが効かないケース

検索結果が多い

フルスキャンしてもパフォーマンス同じ

全体の件数が少ない

全部のレコード数が少ない場合はインデックス使わなくても早いので使われない

この辺のケースはインデックス使っても変わらないので、使われないのが正しいといえる

条件にその列を使っていない

where age * 10 > 100 みたいな

あたりまえ

カーディナリティが低いものに対する検索

性別 = 男　みたいな

あいまいな検索

likeは前方一致のみ

オプティマイザの統計情報が偏っている場合

これどうやったら起こるんだろう

第5章 フラグの闇

削除の手順

delete_flag を立てるだけ

既存のブログを編集した場合

もともとの記事を消して、新しい記事を insert する

編集履歴を持つためにこうなっているっぽい？

有効なブログを取り出すクエリ

あらゆるテーブルの deleted_flag を見る必要がある

ここまでひどいことになるか？

与信

後払いかどうか

第7章 隠された状態

銀行の口座番号とかみたいに

3桁が支店番号で、それ以降が口座番号、とかなっていると、支店ごとの集計とかがやりづらい

第12章 監視されないデータベース

死活監視