自営を始めてからというもの、めっきり設計書というものを書かなくなってしまった。自分でデッサンするのに、UMLを使う程度。

納品条件にはナイので、自分の方から「設計書はどうしますか？」と聞いても、大抵は「それで高くつくのならイラナイ」と回答が返ってきます。
楽になるのはうれしいんだけど、ボクもプロの端くれである。
ボクが死んでしまったとき、誰かが引き継がなければならないことを考えると、必要最低限のドキュメントは、納品しておきたい。

Railsなら、RDocとRailroadで十分だと思っています。
AkelosなどのPHPフレームワークなら、phpdocと、何を使おうか。。。
と探して、DBDesigner4を使うことにしました。

コレがオープンソースって、スゲーな！と思わせるツール。無償DB設計ツールとしては、Eclipseプラグインとかの100倍いいです。

MySQL5で使う場合、いつものOLD_PASSWORDの問題に引っかかってログインに失敗するので、

とします。
で、DBDesigner4のメニューから、「Reverse Engineering」を選択して、対象DBを選択すれば、一発でER図が出力されます。



エンジニア同士の会話に必要なドキュメントであれば、これで十分でしょう。カラム名が意味不明なものだったりしたら、設計書はバッチリ残して欲しいのだが、今日び、そんなカラム名を使う人、もういないよね？
ね！？。

皮肉にも、オブジェクト指向が普及してからではないだろうか。

データ指向・正規化云々が主流だったころのER図は、読めたもんじゃなかった。カラム名や集約・関連が、業務を表していなかったからです。なんだか分からないエンジニアの個人的な執着が入り乱れた、奇怪なER図、ありますよね。

いわゆるO-Rマッパは、リレーショナルデータベースの使い方を、より標準化したんじゃないでしょうか？技術的にではなくて、文化的に。
ＯとＲの違いを吸収する、というよりは、ＲをＯ化した。そんな印象を持っています。

ER図を見て、ソースコードを見れば、何をやってるか直ぐにわかるようになったのは、Railsライクなフレームワークが、ソースコードの大部分を宣言文の集まり（メタプログラミング）にしてしまったから。


オブジェクト指向やRails、新しいものと融合して、いつの間にやら、
ER図がこれほど役に立つ道具になっていた。
図は何も変わっていないのにね。これはちょっと新鮮な発見でした。