本「達人に学ぶDB設計徹底指南書」

前半はだいたい理解している内容なのでざっと読んだ。おもしろいのは7章からだろう。7章は「論理設計のバッドノウハウ」である。

7-2 (p.193)では

配列型は利用しない。第1正規形を守ろう。

とある。理由としてはいくつか挙げているが、同じページで

しかし、原則として配列は、3-4節で見たように「列」ではなく「行」で表現すべきなのです。

とある。僕はそこまで原理主義的に考えることはないのではないかと思っている。もちろん外部要因によってRDMSを移行することがある場合を考えるときちんと正規化しておくほうがいいだろう。（配列型は有名どころではPostgresqlしかサポートしてない）

しかし、よくある「タグ」をどうやって持つか？という問いに対して、配列型は一つの解だと思うし、「使えるものは使ったらいい」と思う。

7-5の「テーブル分割」もおもしろい。直近のデータはよく検索するから同じテーブル構造だけど、「直近1年分」と「それ以前」に分けるというやり方である。

これはあくまでパフォーマンスが理由であり正規化の理論上はおかしいと指摘している。まさにそのとおり。そして解としては「パーティション」を挙げている。

なるほど！

実際、直前のプロジェクトでパーティションは使っていたけど点と点がつながった感じ。パーティションは有効ですよ。

8章「論理設計のグレーノウハウ」もおもしろい。「グレーノウハウ」とは著者の造語である。意味としては、

システムの世界にも、やはりグレーゾーンは存在します。バッドノウハウとはっきりだんげんすることこそできないものの、無神経に使うと開発や運用に師匠をきたすような、そんな毒を含んだ設計のことです。

とある。

8-2「代理キー〜主キーが役に立たないとき」は、よくある「サロゲートキー問題」である。

僕はオートナンバーなサロゲートキーは全然ありだと思っている。もちろん最近のフレームワークがそれ前提だからというのもある。

しかしこの本の中ではデータモデリングの原理主義的に考えると「自然キー（ナチュラルキー）」を使うべきであり、サロゲートキーは推奨しないと言っている。

自然キーというのは「業務的に一意が保証されるキー」ということだ。しかし業務なんていくらでも変わるのだ。外部要因によってキーがかわるというのはとても厄介である。サロゲートキーを使っていればシステム内部で閉じたキーなので外部要因によって変わりようがない。これは大事だと思う。

しかしこのあたりは宗教戦争に近い論争だと思う。設計者が自分が作っているシステムが破綻しないように選択する必要がある。

9章「一歩進んだ論理設計〜SQLで木構造を扱う」も読んでいて面白い。

トラディショナルな隣接リストモデルから、入れ子集合モデル（初めて知った）やそれを発展させた入れ子区間モデル、またファイルシステムを思い浮かべると理解しやすい経路列挙モデルが挙げられていて、それぞれわかりやすく説明されている。

データベース関連の技術書はつまらない（と感じる）ものが多いと常々思っていたがこれは面白かった。