システム開発の現場で、あまりDBの論理設計を担当することって、あまり無い。
と言って、IT系の資格っていっぱいあるけど、DBの論理設計するための資格って無い。

で、企業では、システムを長年使ってきた結果、コード体型が複雑になって、適正化しようという話になりがち。

我が社もそんな状況だったので、読みやすそうなこの本を買ってみた。

この本では、ただひとつのことしか言ってない。
『テーブルには、IDを付けろ。そして、それは意味のあるものにしてはいけない』

これには、鱗が落ちた。

うちも顧客マスタのキーには、8桁のお客様コードを付与するが、そのコードがお客様や現場のユーザーが直接意味とあるものとして使ってしまっており、他の連携するシステムもそれを意図して作られているため、このコードの桁を一つ増やすだけで、物凄いインパクトになってしまうのだ。
あぁ、この本読んで、IDさえ振っておけば、なんとかなったのに。

他にも、DBの設計するには当たり前のことでも、自分が知らないことがあったので、DBなんて、所詮データの入れ物だろ？なんて、思ってるプログラマーには是非読んで欲しいです。（自分もそうだったから）

順を追って何度も呼んでいくとDB設計の実践方法が身につくように
出来ています。

SI業者さんでなかなか設計の仕事が回ってこない若い人や
ACCESS等のRDBMSの上級エンドユーザにおすすめ。

ただ一点、ERDの表記法IDEF1Xについて、説明が無いのが残念です。

RDBのテーブルの設計やらモデリングやらのポイントを丁寧に説明している本です。

自分は、特に、モデリングの部分がおもしろかったです。
実際のレシートやら図書館の予約表やらを題材にして、
そこから得られる限られた情報から、時には十分説得力のある推量もまじえて、ぱぱっとE-R図をつくっていくようすがとても参考になります。

題材を見たら、まず自分でE-R図をつくって、そのあとで説明を読むようにしていました。
「ああー自分のモデリングではそこは見落としてた」なんてのがしょっちゅうあってためになりました。

こっち方面の勉強中というひとは買いです！

10年早く読みたかった。

そうすれば、不合理なコード体系に振り回されて工数を空費することもなかったし、DAOの粒度を無意味な大きさに統一することもなかった。まだ記憶に新しいアノ不具合も作りこまなかった。後悔しきりだ。奥付を見ると２００６年の出版とある。となると最短で読んだとしても、あの不具合とアレくらいしか救えなかったかな…それでも結構大きいぞ…と胸算用してしまった。

そのくらい生々しいノウハウが、書かれている。

著者が失敗から学んだことだろう。私も似た失敗をして学んだことが多く書かれていた。だから技術書なのに"赤裸々"な感じがするのだ。

勘定系システム開発とは切っても切れないデータベース設計での失敗、落とし穴、そして肝心の回避策が多く書かれている。そんじょそこらの先輩・研修講師には決して教えてもらえないような質・量だ。１年生には難しすぎるけど、２年生なら十分に読みこなせるだろう説明の仕方もすばらしい。

この本は、DB設計の肝であるERDについて書かれています。
筆者の経験とこれまでに読んだモデリングの本の知識がまとめられており、
実際の伝票や請求書のフォームから、適切なER図を描くにはという点や
SQLにまで触れられています。
ただ、ERDというかデータベース設計を行う上での基本的な用語については
解説されてませんから、それらは別の書籍などで補う必要があります。
その様な入門書を読んでみてSQLを多少触ってみて、さてこれから実際に
どうしようという時に、この本は強い手助けになるのではないでしょうか。