DB設計の3段階って必要なんだろうか

なんかぼんやり思ったので自分用にメモ。特に強い結論があるわけではない。

よくある

• 概念モデル
• 論理モデル
• 物理モデル

ってやつ。

物理モデルについては ActiveRecord + Rails-ERD などで作り方を逆転させることも可能。これに慣れると抽象的なモデリングってほんとに必要なのかなという気もするけど、それはたぶんプロダクトの特徴を熟知しているから可能なのであって、何をしようとしているのかさえ不明瞭な状態ではいきなりは無理。

概念モデル、論理モデルはコミュニケーションのためのものと割り切ればよいのかもしれない。

概念モデルはやりたいことに名前を付けて、必要そうなシステムを洗い出すためのもの。

論理モデルはその際に必要になるデータの制約に注目するためのもの。何と何が紐づいているので、とか、どういう変更がどのタイミングで入るのか、とか、絶対に欠落したらダメとか。

いずれもコミュニケーションのためなら母語で書かれてよい。ただ、論理モデルで考えてる制約の話は物理モデルから出てきている部分があって、やはりもやもやは残るんだけど、頭の中である程度の物理モデルが作れる人が論理モデルで会話できるようになる、ってイメージかなぁ。物理モデルの経験がある程度以上ないと論理モデルが挟まるのは単に面倒が増えるだけというか、逆に難しい感じがする。

物理設計はパフォーマンスまで考えるって話があるけど、正規化してる段階でパフォーマンス考えてますよね、とか、なんかもやもやを感じたもので。はい。

いや、はい。だから特に結論はないってば。