[書評]達人に学ぶDB設計徹底指南書初級者で終わりたくないあなたへ

達人に学ぶDB設計徹底指南書初級者で終わりたくないあなたへ
著者 : ミック
翔泳社
発売日 : 2012-03-16
ブクログでレビューを見る»

DB設計の基礎知識と実践的なノウハウをわかりやすく解説した本。
SQLを使うだけでなく、テーブル設計などを始めたら読んでおきたい。

第１章のタイトル「データベースを制するものはシステムを制す」は
システムエンジニアの金言と言っても過言ではないでしょう。
DB設計がダメだとシステム開発の難易度が跳ね上がるので
DB設計者には本書の内容を身につけておいて欲しいですね。

翔泳社刊行物Q&A:達人に学ぶDB設計徹底指南書正誤表

データベース初心者がSQLを極めるためのオススメ書籍6冊 | DevAchieveのうちの１冊です。
達人に学ぶ SQL徹底指南書はまだ読んでいないですが、次あたりに読もうと思います。

さて、達人に学ぶDB設計徹底指南書の内容ですが、まずは目次を見ましょう。

第1章　データベースを制する者はシステムを制す
第2章　論理設計と物理設計
第3章　論理設計と正規化～なぜテーブルは分割する必要があるのか？
第4章　ER図～複数のテーブルの関係を表現する
第5章　論理設計とパフォーマンス～正規化の欠点と非正規化
第6章　データベースとパフォーマンス
第7章　論理設計のバッドノウハウ
第8章　論理設計のグレーノウハウ
第9章　一歩進んだ論理設計～SQLで木構造を扱う

第1章はDB設計の重要性と3層スキーマ(外部スキーマ、概念スキーマ、内部スキーマ)について解説しています。

概念スキーマの大切さについて論じられていて、わかるわーってなりました。変更時に残念な事になるからね。

第2章は論理設計と物理設計の流れ、考えるべきことについて解説しています。

バックアップとリカバリはほとんどやったことがないので難しそうだなぁ(そして責任重大だなぁ)と思いました。
フルバックアップの欠点としてサービスの停止が必要とありましたが、
停止しなくても MySQL で InnoDB ならmysqldump --single-transactionで
テーブルをロックすること無くバックアップを取ることができるので違うのかな？と思いました。
余談ですが、初めてフルバックアップするときはサービスは停止できないし、
テーブルがロックされたら参照/更新できなくなってとんでもないことになるしで
マニュアルやエキスパートのためのMySQL[運用+管理]トラブルシューティングガイドを読んで
mysqldump --single-transactionで良いんだよなとドキドキしながら実行したことを思い出します。
MySQL :: MySQL 5.1 リファレンスマニュアル :: 7.12 mysqldump — データベースバックアッププログラム
更に余談ですが、あの本って漢(オトコ)のコンピュータ道の中の人が書いた本だったんですね。

第3章と第4章は正規化とER図ということで、設計にあたっての基礎知識を解説しています。

このへん、１冊の書籍としてまとまっているのはありがたいですね。
DB設計の基礎知識を身につけさせたかったら、コレ１冊渡してあげればなんとかなりそうです。

第5章は正規化とパフォーマンスのトレードオフ関係について解説しています。

論理設計は大事だけど、論理設計には物理設計の知識が必要ってことでした。
どんなに綺麗に正規化しても物理設計から離れてはいけないのだ、と。
正規化しすぎると JOIN が増えてパフォーマンスに問題が出るからバランスとるのが難しいですね。

第6章はデータベースのパフォーマンスについて解説しています。

B-tree インデックスは名前だけしか知らなかったので勉強になりました。
統計情報は意識したことないし、InnoDB なら基本的に意識しなくて良いみたい。
漢(オトコ)のコンピュータ道: 大人のためのInnoDBテーブルとの正しい付き合い方。

第7章と第8章は論理設計のバッドノウハウとグレーノウハウについて解説しています。

自分で体験できる論理設計の場面は限られているのでこのようなケーススタディは勉強になります。
そんなに規模が大きくないとバッドノウハウでも何とかなっちゃったりするので
何がバッドかどうかというのを知っておくのは良いですね。

第9章は応用編でリレーショナルデータベースが苦手とされてきた木構造について解説しています。

隣接リストモデルは子が親の ID などを持つことになるかと思いますが、 SQL がかなり複雑になりますね。
葉(leaf)から根(root)を探そうと思うと
自己結合するクエリをループで複数回実行することになって微妙だったことがありました。
入れ子集合モデルや入れ子区間モデル、経路列挙モデルが紹介されていますが、どれも大変そうなイメージです。
まず、これらのモデルを知らない人がカラムの意図を理解することができなそうで大変そうだと思いました。
入れ子区間モデルとか良さそうでしたけど親や兄弟を探すのとかどうやるんでしょうね？
あと、例えば Twitter のリプライのツリーみたいに必ずしも親を持つわけではない場合に
親がいるかどうかの判定がめんどくさそうなのと、その値のマッピングが難しそうだと思いました。
やっぱりそういうのは隣接リストモデルの方がいいんでしょうね。Twitter のテーブル定義が見てみたいですね。

著者のミックさんの書いた解説が Web 上にあるので気になったら読んでみると良いと思います。
SQLで木と階層構造のデータを扱う（１）―― 入れ子集合モデル
SQLで木と階層構造のデータを扱う（２）―― 経路列挙モデル
SQLで木と階層構造のデータを扱う（３）――入れ子区間モデル
他にも色々解説を書いているので SQL ある程度出来る人は読むと勉強になると思います。
リレーショナル・データベースの世界