Rails時代のテーブル設計について

　本職でDB関係の設計やチューニングをすることもあるのですが、それについて最近思うこと。RailsやSeasarとかフレームワークは進化しつづけているのに、テーブル設計の方法論については進化に乗り遅れているんでないのというところ。例えばアプリ側の視点からすれば、業務コードを主キーに使うような下のような設計はもうありえないと思います。（ビジネスルールで決まる受注番号と、受注明細番号を主キーにする）

　主キーには業務上で一意に識別されているコードではなく、意味もないIDを使いましょうというのが今の主流だと思います。（ですよね？）上記の図のケースだと、下のような形に置き換えるのが適当かと思います。

　ただ本屋でテーブル設計の本とか読んでも、ほとんど10年前の設計のまま。（上の図のケースです。）私が知る限り、最近のフレームワークにまっちするようなテーブル設計の仕方を教えてくれる本は、羽生さんの楽々ERDレッスンだけです。もう少しDB設計側からも、最近のフレームワークに適合するような形の設計手法を出して欲しいものですね。

　あと、フラグとか撲滅したいので、その辺り詳しい本ないかなぁ。

楽々ERDレッスン (CodeZine BOOKS)