yukungのブログ

yukungの技術ブログ兼駄文置き場 

楽々ERDレッスンを読んでいます

ここのところ、ちょっとしたWebアプリを書いています。そこでDBのテーブル設計についてああでもない、こうでもないと悩んで一向に手が進まなかったので、テーブル設計について体系的に学んでみたいと思うようになってきました。あくまでも自分が使うためのWebアプリなので、設計がどうとか保守性がどうとかあまり悩む必要もないのですが、そこは私もエンジニアの端くれ、自分で100%自由に設計できるからこそ、作り込みたいと思うじゃないですか。
で、本を読みたいなぁと思ったんですが、思い返してみると自分が所持しているDB設計についての書籍は、

データベース設計 構築 基礎+実践マスターテキスト

データベース設計 構築 基礎+実践マスターテキスト

くらいしか持っておらず*1、大学時代と情報処理試験の勉強で正規化やトランザクション辺りの話は勉強したものの、それからきちんと勉強した機会がないことに気づきました。実務でもテーブル設計はベテランの方々の領域ですしね…。
そこで、まずはいい本ないかなーとぐーぐる先生に聞いてみたところ、一つのBlogに辿り着きました。
Rails時代のテーブル設計について - プログラマになりたい
ここで述べられていることは、普段私が業務でよく見かけるテーブル構造と、プライベートで眺めているOSS*2ツールなんかのテーブル構造との間で、私が感じていたもやもやとした違和感・ギャップを的確に捉えていました。

RailsSeasarとかフレームワークは進化しつづけているのに、テーブル設計の方法論については進化に乗り遅れているんでないのというところ。例えばアプリ側の視点からすれば、業務コードを主キーに使うような下のような設計はもうありえないと思います。(ビジネスルールで決まる受注番号と、受注明細番号を主キーにする)
主キーには業務上で一意に識別されているコードではなく、意味もないIDを使いましょうというのが今の主流だと思います。(ですよね?)上記の図のケースだと、下のような形に置き換えるのが適当かと思います。

確かに業務でよく見るテーブルはfooコード+barコードの複合キーを主キーにしているテーブルばかりで、そのくせそのコードは業務的な意味を持つためにつけ替えや変更、再利用が行われ、その度アドホックなソースコード修正が入っています。データを取得するためのSQLも複合キーのJOINだらけなので、いたる所に影響が出てしまうことが多々あります。
一方で、OSSツールのER図なんかを眺めてみると、単に「ID」という主キー(主に連番)が振られ、他のテーブルはそれを外部キーとして持ってるだけ、というシンプルなテーブル構造になっています。IDはあくまで他のテーブルとのポインタの役割を果たしているにすぎず(意味を持たない)、基本的には変更されません。そのため他の業務的(意味を持つ)属性が変更されてもリレーションに影響はなく、変更に強い構造になっています。
そして、

ただ本屋でテーブル設計の本とか読んでも、ほとんど10年前の設計のまま。(上の図のケースです。)私が知る限り、最近のフレームワークにまっちするようなテーブル設計の仕方を教えてくれる本は、羽生さんの楽々ERDレッスンだけです。

とのこと。であれば、読むしかないだろjkとばかりに、速攻書店に行って買ってきました。

楽々ERDレッスン (CodeZine BOOKS)

楽々ERDレッスン (CodeZine BOOKS)


羽生さんには以前WEB-DB PressのTech Meetingでのプレゼンですっかりやられてしまっているので*3、個人的にはその羽生さんの本というのがまた他の本とは一線を画している気がしますw

で、今読んでいます

まだ第2部の途中までしか読めていませんが、さすが羽生さんの書いた本だなーというのが随所に現れています。断定的なところとか特にw
ですが、決して根拠ない断定ではなくて、豊富な実務経験からの断定なので説得力ありまくりです。IDの導入やビジネス上の観点からの正規化など、DBの設計理論に原理主義的に従うのではなく、目的は実務で使いやすくすることでしょ?という観点からどうある(する)べきかが明確に書かれているので、業務でDB設計している人も納得できる内容なのではないでしょうか。
つーかSIerで設計している人はこの本は読むべき。特に汎用機での開発が自身のバックボーンで、RDBじゃなくCOBOL&JCLでフラットファイルをゴニョゴニョいじくってた人は。うちの現場の“ベテラン”の方々に読ませたい。

*1:これも新人研修のときに会社でもらったもの

*2:WordPressとか

*3:説得力的な意味で