●本を手に取った背景
データベース設計に関しては応用情報技術者試験レベルの知識レベルで停滞している（データベース系資格には手つかず）が久しぶりにほぼイチから自分で設計する羽目になったので、少し応用寄りのデータベース本を一冊読んでおこうとそのあたりに転がっていた本に手を付ける。●全体として
SQL文の仕様や説明等は書いておらず、ある程度分かっていることを前提に、データベースの設計に特化。（SQL文のチューニング本ではなく設計ノウハウ中心。）ついやってしまいそうなバッドノウハウ、グレーノウハウ集は、イチからDBを設計する・DBに大幅修正かける機会があるたびに読み直したいところ。●メモ、ポイント（もう一度読み直す際の栞、もう少し追加で調べておきたいこと等）
- データベースの性能問題の８割はディスクのIO。P.36
- ベンチマーク指標SPEC（Standard Performance Evaluation Corporation）。ただ自分が開発しようとしているシステムの処理モデルがそれに近いとは限らない。基礎数値としては使えるかもしれないレベル。P.39
- テーブル名で使えるのは半角英数字＋アンダースコア。ハイフンはNG。数字で始まってはダメ P.80
- なぜRDBを関係モデルと呼ぶか。表モデルじゃないのか P.81
- 第四正規化、第五正規化が割と分かりやすい
- 正規化の功罪あれど非正規化は最後の手段。P.148 （うっかり使いがちな気がするがダメらしい）
- B-treeインデックスのBが何かは不明ｗｗ P.167
- データが少ないとインデックスつけないほうが速いことがある。１万～。P.171
- カーディナリティの高い列に。全体に対して5%以下に絞り込めるものが良い。特定の値ばかり多いのにも向かない。P.175 （なんでもwhere句にしそうなものにはつけときゃいい、って言うわけではないのか）
- インデックスが本当に働いているか注意。例：A*1.1>100ではNG。A>100/1.1ならOK。否定形、orもダメ。後方一致のlikeもダメ。暗黙の型変換もダメ。P.176 （……結構やってそうだよなぁ）
- 主キー、一意制約の列には勝手についてるからつけなくてよい。P.179 （へー）
- オプティマイザ。実行計画、統計情報収集。P.180 （こういうのデフォルトで放置しがちだよなぁ）
- 配列型。P.192 （あったんだ！！ ……でも推奨されないらしいｗ）
- 水平分割ではなくパーティション機能を用いる P.206
- オートナンバリングをアプリケーションで実装するのは危険 P.238（コードに連番つけるときついやっちゃいそうなんだけど）
- 木構造の解法。「入れ子集合モデル」「入れ子区間モデル」等新しい解法も提案されている。P.267
