<a href="http://www.amazon.co.jp/%E9%81%94%E4%BA%BA%E3%81%AB%E5%AD%A6%E3%81%B6DB%E8%A8%AD%E8%A8%88-%E5%BE%B9%E5%BA%95%E6%8C%87%E5%8D%97%E6%9B%B8-%E5%88%9D%E7%B4%9A%E8%80%85%E3%81%A7%E7%B5%82%E3%82%8F%E3%82%8A%E3%81%9F%E3%81%8F%E3%81%AA%E3%81%84%E3%81%82%E3%81%AA%E3%81%9F%E3%81%B8-%E3%83%9F%E3%83%83%E3%82%AF/dp/4798124702%3FSubscriptionId%3DAKIAJSJNHUSHZBCW2UMQ%26tag%3Dtnnsst35-22%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3D4798124702" title="Amazon で商品の詳細を確認する"><img src="http://ecx.images-amazon.com/images/I/51vol70XHoL._SL160_.jpg" alt="達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ" /><br />達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ</a>
読んだ。 リレーショナルDBの設計に関して書かれた本。
論理設計：エンティティの抽出、リレーションの定義、正規化 物理設計：テーブル定義、インデックス定義、ハードウェア、RAID、バックアップ、復旧
こういったことに関して基本的なことが網羅されている。特に多いのは正規化の話。 また、トレードオフに関してもよく書かれている。
正規化に関して言えば、この本の結論としては「第３正規化まではやりましょう。」ということ。 正規化のトレードオフとしてパフォーマンスの問題点にも触れたうえで、パフォーマンスのための非正規化の手法も紹介されているが、「非正規化は最終手段なので、あくまで正規化をやりましょう。」ということ。
あとは、「論理設計のバッドノウハウ」「論理設計のグレーノウハウ」という章が特徴か。
「テーブルをつくるときは主キーになるid列を必ずもちましょう」と教わったり、そもそもフレームワーク（ORM）としてid列をもつことを推奨しているものを使ってたりして、全てのテーブルにid列を持つのが自分のなかでは習慣になっていたが、この本ではそれをグレーノウハウだとしている。 自然キーで解決できる場合はそれを使うべきということ。
例えば、users : user_action_logs = 1 : n の関係のテーブルがある。
users - id - name - age primary (id)
user_action_logs - user_id (FK) - action_time primary (user_id, action_time)
※(FK) = 外部キー
user_action_logsはユーザーの行動履歴を保存するテーブルだとして、主キーはuser_idとaction_timeみたいな風にしましょうという話。 id列を持ちましょうというグレーノウハウを用いるとuser_action_logsは以下のようになる。
user_action_logs - id - user_id (FK) - action_time primary (id)
なかなか難しい話でした。
