前置き？
情報は何かを活かすためのデータ。データは事実だけの集まり
1章 ジェイウォーク（信号無視）
1つのカラムにhoge,fugaみたいに複数の値を入れるのはやめよう
2章 ナイーブツリー（素朴な木）
階層型のテーブルを表現する時は、系列列挙（gem ancestorsのやつ）が安パイ。ただし参照整合性を持てなかったり、パフォーマンス面にやや不安あり。
3章 IDリクワイアド（とりあえずID）
ただしactiverecordみたいなORMだと、自動でidが生成されるのは問題なし。設定より規約だから(Coc)
4章 キーレスエントリ
外部キー制約はちゃんと貼ろう。思わぬ箇所でエラーが発生する恐れがある。データに不整合を生む可能性があるから、原則つけること
たまに外部キーつけないで実装しちゃうことあったから、常日頃から外部キー制約をつける習慣をつくる
5章 EAV（エンティティ・アトリビュート・バリュー）
カラムの内容をテーブルで動的に管理するのは、コストが高すぎるので基本的にやらない方が良い
6章 ポリモーフィック関連
基本的にめんどくさいから触らないほうが良い。無理して使う必要はない。どうしても必要な場面があった時に検討するぐらい。
7章 マルチカラムアトリビュート
このアンチパターンを破ってもいいのは、下記の2パターンが多い
・変更される可能性が極端に少ない
・1つのカラムに同じ値が入ることが保証されている
8章 メタデータトリブル（メタデータ大増殖）
増加が予想されるカラムを列持ちしない
パーティションか別テーブルに切り出す
検索するのが鬼辛い。でも履歴テーブルなどは例外
年度ごとに分けるテーブルだったり正規化は大事。変更にめっちゃ柔軟になる。カラムで管理すべきものとしないものを考える。
方法は、当たり前だけどそれぞれのメリット・デメリットと行動を網羅的に考える
9章 ラウンディングエラー（丸め誤差）
給与や金額、時給だったり小数点がある数値の計算は、DBとかプログラミング言語の仕様上、人間が思った挙動にならないパターンが多い。
10章 サーティーワンフレーバー（31のフレーバー）
ENUMは変更コストが高いので、あまり使わないほうが良い。
変更が疑われる複数の状態を持つカラムは、別テーブルに切り出すのもおk
11章 ファントムファイル（幻のファイル）
carrierwaveとかは画像を格納するんじゃなくて、画像のパスを格納してる。曖昧な理解でした
画像をDBに保存するか、S3みたいな外部に保存するかはよく仕様検討すること。メリットデメリットを洗い出して網羅的に考える。
12章 インデックスショットガン（闇雲インデックス）
Rails出身者だったり、インデックスはただ貼れば処理が早くなるって思い込みがちだと思った。自戒。
インデックスの役割とかデータベースの仕様を理解して、適切にインデックスを貼る。
カーディナリティとかも考える。
データベースによってインデックスの仕様が違うのは厄介だなーって思った。
MySQLは値が散らばってるほどインデックスが有効とか。
数値の計算後の値をインデックスで検索したりとかはやらないこと。
パフォーマンス分析の手法で、MENTORってのがある
13章 ふぃあ・おぶ・じ・あんのうん（恐怖のunknown）
NULLの仕様を理解して向き合う
SQLでIS NULLでNULLを返す理由が理解しきれてない。値の分類が3つあるのは分かる。
NULLの思わぬ挙動で、意図した結果が取れた！って勘違いするケースもある。
14章 アンビギュアスグループ（曖昧なグループ）
曖昧なクエリ結果を避けるために、単一の結果を返すSQLを書け
15章 ランダムセレクション
ランダムな処理は基本的にSQLでやるのは良くない。
全県取得した後に絞り込むっていう処理をするせいで、メモリに無駄が発生する。
最初は処理が軽く見えて、レコード数が増えてくると重くなって牙を出す。
それで苦しめられる人が以外にも多いらしい。
16章 プアマンズ・サーチエンジン（貧者のサーチエンジン）
LIKE句で部分一致で検索する人は多いけど、それは良くない。
全県探すっていう方法を取っちゃうから。
やるとしたら、MySQLは文字列にインデックスを貼る？みたいな仕様があるらしい。
ただし可読性とか工数は劣るから、必要に応じて使い分ける。LIKE句を使うのが絶対悪じゃない。ケースバイケース
17章 スパゲッティクエリ
一度で複数の結果を返すようにするな。シンプルにしろ。
後で管理しやすさだったり、他の人が読むときにも読みやすくて理解しやすい。
長すぎると改修がくっそむずくなる
18章 イグジットカラム（暗黙の列）
思考停止でセレクト句とワイルドカードを使ってると、思わぬところでエラーを吐くかも。
列指定でSQLを実行するな。
多少手間でもほしいテカラムを明示したほうが良いらしい？
19章 リーダブルパスワード（読み取り可能パスワード）
セキュアにするためにパスワードは解読できるようにするな。
ただしサブアプリだったり、パスワードが漏れても問題ないものは例外になる可能性あり。
20章 SQLインジェクション
activerecordみたいなORMに頼ってると、SQLのセキュリティーを考える機会は少ないけど、実際は深く考えるべき。特にユーザーがパラーメーターを送れる時。
思わぬ方法で突破してくるから、網羅的に考える。
具体的な対策は、パラメーターを送れるのを制限する、文字列に加工する。とか
21章 シュードキー・ニートフリーク（疑似キー潔癖症）
自動生成のIDを再利用しては絶対にいけない。もしやるなら、自然キーを使う。前に実際に要望があってIDを再利用しかけたから気をつけねば
22章 シー・ノー・エビル（臭いものにフタ）
エラーメッセージをしっかり返そう。DRYにならなくても例外処理はしっかりやること。
良いアプリの50％はエラーハンドリング系の処理だとか
23章 ディプロマティック・イミュニティ（外交特権）
アプリエンジニアだから、DBにアクセスできないから、俺は関係ないからDBは理解しなくて良い。っていう考えはやめろ。
DBに少しでも関連するなら、常に仕様を理解しておく。
24章 マジックビーンズ（魔法の種）
モデルに何でもかんでも詰め込みすぎると、疎結合じゃなくなって詰む。
モデルはテーブルから分離させる？