# Database Design

> DB のテーブル・カラム命名を、処理目的ではなく永続化する概念・entity・関係から判断するためのスキル。DB命名、スキーマ命名、正規化に伴う命名、用途に過適合した名前を避けるときに使用する。

- Skill: `efoo-team/database-design` (Agent Skill)
- Install (CLI): `npx skillmds@latest add efoo-team/database-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/efoo-team/database-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: efoo-team (https://skillmd.com/u/efoo-team)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/efoo-team/database-design

---


# Database Design

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

---

## テーゼ

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

---

## good / bad 例

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

**ユーザーのメールアドレスを取り込む**
取り込み処理が起点でも、保存される概念はユーザー、またはユーザーに紐づくメールアドレスである。
```
good
- users
- user_emails
bad
- user_imported_email_addresses
```

**注文画面に表示する明細を保存する**
画面表示が目的でも、保存される概念は画面用の明細ではなく、注文に含まれる明細である。
```
good
- order_items
bad
- order_items_for_display
```

**外部サービスから取得した会社情報を保存する**
取得元はメタデータになり得るが、主概念そのものを取得経路で命名しない。
```
good
- companies
- company_external_refs
bad
- crm_imported_company_records
```

**エクスポート用に住所を保持する**
エクスポートは利用目的であり、保存される概念は住所である。
```
good
- addresses
- shipping_addresses
bad
- addresses_for_export
```

---

## チェックリスト

- [ ] 保存したい内容を、実装都合（処理・画面・連携・入出力）を除いて言い換えたか
- [ ] それが entity・属性・関係・事実・状態のどれかを分類し、その概念に直接名付けたか
- [ ] 名前は「何をするか」ではなく「何であるか」を表しているか
- [ ] 現在の処理・画面・連携・入出力を知らなくても意味が通るか
- [ ] テーブル分割・正規化の理由は用途ではなく、entity・関係・制約・ライフサイクル・cardinality の違いか（分割後の各名前も概念名として成立するか）
- [ ] 別の用途・別の作成/参照経路が追加されても名前が嘘にならないか