Database Design

DB の命名は、タスクに名前を付けることではない。永続化する概念を抽象化し、その概念に名前を付けることである。名前が特定用途に結びつきすぎると、用途が増えた時点で名前が嘘になり、局所最適化されたテーブルやカラムが増える。

テーゼ

• 何であるかで名付ける。 命名前に処理目的・画面名・連携元・入出力形式をいったん取り除き、残った概念に名付ける。名前に取得方法・利用先・表示都合・同期都合・ジョブ都合・入出力都合が残っていたら、それが本当にドメイン概念かを疑う。別の用途・別の作成経路・別の参照経路でも成立し意味が変わらないなら、概念名として再利用に耐える。
• 分離はモデル構造で判断する。 正規化やテーブル分割は、用途があるからではなく、独立した entity・属性・関係・ライフサイクル・制約・cardinality を表す必要があるときに行う。テーブルが増えること自体は問題ではない。問題は、分離の理由がデータモデルではなく一時的な処理都合になっていることである。

good / bad 例

以下はテーゼを説明するための例であり、そのまま命名規約として固定するものではない。