ER図とDB設計とクラス設計について

ちょっと最近スクラッチで作るプロジェクトが始まったのと、TwitterのTLで気になる話題があったので簡略に考えてみる。
まじで簡略に

議題としては、RDBにおいて

この3つの事項に対しての意味と、作業の優先順位・着手順といったところ。

DB設計より先にクラス設計を行うべきか

簡単に一概していえない物を一概にして考えをいってみると

アプリケーションの役割の比重が低い場合が概ねそうだと思う。

アプリケーションの役割の比重が低いほうが、クラス設計が重要になるというのがちょっと不思議かもしれないけど、スピーディーに開発することが重要で、かつ適切なDB設計を行わなくても問題ないアプリケーション。
例えば、ORマッパーを使用できる（使用して問題ない）アプリケーションの場合はそうだと思う。

つまり、極端に言ってしまえば入れて出すだけのアプリケーションなら大したreadも行わないしそれこそ開発効率を最優先してコードファーストで書いてそれに合わせてＤＢが作成されてしまえばいい。
オブジェクトを永続化できれば良いのだから。

という考え。

エンティティが完璧に出来上がるならそれでもうほぼ終わりでいいじゃん！みたいな空気になる

そんな状況。
だって正規化って結局DRYの法則に従ってるだけで、クラスをDRYに設計する以上DBもDRYになるし… 　

品質を担保するのが難しいアプリケーション（パフォーマンス面で）

非正規化ガンガンうぇるかも！な状態。むしろ非正規化しないとやってられねーよ、とか、概念モデルや論理モデルが物理モデルを圧倒しちゃうようなアプリケーション。
カーディナリティを考慮せずに設計するなんてアリエナーイ！とか
ORマッパーなんて使用してたらパフォーマンス的にムリゲーとか。

そのほか複数のアプリケーションがそのDBをつついてくる場合（アプリケーションの数だけ役割があるので）

まとめると、クラスの意義でもある「データ」と「操作」をまとめられない時という感じかなぁ…
データと操作は考える上では一緒だけど（だってインデックス設計のときに操作分からないと無理だし…）、システム的な面でデータと操作をまとめてしまうと障害が出てしまうときに。

あとは分散トランザクションなんかが必要な時って、そもそもDBないとクラス設計そのものが面倒になるし（データの設計だけでも終わってくれてれば、その分楽になるし）

あとデッドロック恐怖症の人は迷わずDB設計からどうぞ。

ER図は、概念データモデルが大量にある時や、完全なデータモデルと概念データモデルが表記上大きいギャップを持った時に便利だと思う。
正直営業資料的な要素を除けば、これが大きいんじゃないかなぁと思う。

概念データモデルが、様々な事象によって物理データモデルから算出しにくい時にある必要がある。（多対多のリレーションがめっちゃある時とか）

自分個人としては、概念データモデルも全てクラス化したいからしちゃうし（コンパイルでテストを減らせるから）でも、その概念データモデルが物理データモデルすぐ分からない場合に、その説明的な物で必要だと思う。

正直、DB設計してそれで概念データモデルも大体分かるならER図書いてる暇あればスキーマ作っておいてそれから生成してくれ。という気持ちも強いｗ

トラウマな開発があったせいで偏見に満ち溢れているけど、クラスで表現しきれる？
○→クラス設計を最優先で行い、その後やっといたほうが良いＤＢ設計なんかと行う

扱う概念モデルが大量にある？
○→ＥＲ図をとりあえず書く

データベースの性能をフルで発揮する必要がある？ ○→DB設計を最優先で行う

※時間とお金が無制限にある人は除く