画面からERD - 豆無日記

デブサミではぶさんのセッションを受けたので、ちょうど今やってる超短期案件のDB設計で試してみました。
画面ごとにDB関連の項目を抽出していって、最後にマージするってやつです。

＃ほとんど素振りなし状態なのですが、どっちにしろやらなきゃならんもので。

ペアで実施したんですが、結論としてはぶさんの意図とはだいぶ違うかもしれませんが、画面デザインや実装方式などいろいろ話が飛びながらも、DBに必要な情報、その使い方がもれなく(たぶん...)網羅できて、詳細設計のプラクティスの1つとしてかなり効果的だと感じました。画面の使われ方、それぞれ画面でのDBとのかかわり方、実装上の注意点などなど、短い時間でかなり深いところまで意識合わせすることができたと思います。ペアの相方がそう思ってるかはさだかではないですが。

ERD的にお稽古不足のため、はぶさんにDB設計レビューされたら怒られちゃいそうな気も多少しますが、今回はあまり複雑なテーブル構成でもないので、多分大丈夫でしょう。

これだけはやっとけ！プラクティスの

通番のレコードIDは必ず独立で用意(○○コードと一緒にしない)
とりあえず交差エンティティ

を守ってやってみましたが、やはり相方から、

やたらID,IDって冗長じゃない？
やたら交差エンティティにするとJOINで遅くならないか？

という疑問が出てましたが、

通番なレコードIDをふったって別に困る訳じゃないでしょ？逆にユニークだからって○○IDをPKなんかにしたら、後々困るんだよ。(経験に基づかない断定)
この程度のテーブル構成＆レコード想定数なら大丈夫。(ほんとか？)
マイブームだからいいの。(死語)

などといいかげんな説明で乗り切ってみたり。お恥ずかしい。

そうそう。ちょっと迷ったところがあったので、かなり初心者っぽい話で恥ずかしいですが、一応書いてみます。

レコードIDをプログラム側でレコードを特定する条件として利用していいのか？
- DBMS側の都合による論理ポインタとしてのみ使う、というようにはぶ式原理主義的に考えると、少しでもプログラム側で意識するのは気持ち悪いんじゃないかと。
- 結論としては、「0番だったら○○、99番だったら××とみなす」というようなマジックナンバ的な使い方をしなければまあいいんじゃないかということにしておきました。

というわけで、明日はばらばらに抽出したDBパートのマージ作業です。