メッセージ。 - にゃー

個人的には、ER図なんて意味がないと思っている。だって、そんなものはスキーマを見れば分かるんだから。スキーマの解読に労力なんてかからないので、それを図に落としただけのER図なんて技術上何の意味もない。
まぁ、その前の前提として、テーブル名やカラム名を見れば、それが何のためのものか分かる程度に綺麗な設計でなければならないけど。それができてないなら小学校からやりなおしてきてって話で。

むしろDBに関してドキュメントが必要なのは、テーブル名やカラム名を見ても使い方が自明でない部分だ。たとえば、あるリレーションを持つテーブルのレコードで削除フラグが立てられたとき、リレーションの繋がっている別のテーブルの値は表示すべきなのかどうなのか。

そもそも削除フラグは何のために使用するのか、実際にレコードを物理削除することはあるのか、ないのか。ユーザー系に表示するときと管理画面に表示するときとで削除フラグの扱いは異なるのか（削除フラグの立ったデータは管理画面にも完全に一切表示しないのか）。

また、一度削除フラグを立てたデータが復活した場合、各カラムに設定されていたデータは残るのか、完全にクリアされるべきなのか？クリアされるべきだとすれば、わざわざ削除フラグを立ててDB内にデータを残していた意味はどこにあるのか？

アプリケーションでの削除フラグの扱いは一貫させることができていたとして、手動でDBをいじらなければいけないとき、どのようなオペレーションが付随して必要になるのか？そもそもこれらの問いに明確に解を与えられるほどサービス要件は明確なのか？

まぁ、そもそも削除フラグが本当に必要なのか真剣に考えろってことだけど。そういった要件をドキュメント化したり実装したりするのが実際の仕事と考えると、ER図を作ることはそれは仕事にあらずという感じがするけど、ぼくは間違っているんだろうか。。