自然キーと代理キー しぜんきーとだいりきー
自然キー代理キー主キー設計UUID連番IDデータモデリング
主キーって何を使うのがいいの？
簡単に言うとこんな感じ！
主キーには「業務上意味を持つ値（自然キー）」を使う方法と「DBが勝手に採番する番号（代理キー）」を使う方法があるよ！一般的には代理キー（連番のIDやUUID）の方が安全で変更しやすいから、現代の設計では代理キーが主流なんだ。
自然キーと代理キーとは
| 種類 | 内容 | 例 |
|---|---|---|
| 自然キー（Natural Key） | データが元々持っている業務上の識別子 | メールアドレス・マイナンバー・ISBN |
| 代理キー（Surrogate Key） | DBが自動生成した意味を持たない識別子 | 連番（1,2,3…）・UUID |
自然キーの問題点
自然キーには以下のリスクがあります：
| 問題 | 内容 |
|---|---|
| 変更可能性 | メールアドレスは変わる。変更のたびに全テーブルを更新 |
| 非ユニーク性 | 電話番号は重複することがある |
| 外部依存 | マイナンバー等は外部システムの仕様変更で影響を受ける |
| 機密性 | 主キーがURLに出ると個人情報が露出する |
| 文字列結合 | 文字列のPKは整数より結合が遅い |
代理キーの種類
| 種類 | 内容 | メリット | デメリット |
|---|---|---|---|
| 連番（AUTO INCREMENT） | 1, 2, 3, 4… | シンプル・小サイズ | 分散DBでの競合・予測可能 |
| UUID v4 | ランダムな128bit値 | 推測不可能・分散OK | 大サイズ・ランダムで断片化 |
| ULID | 時刻+ランダム | ソート可能・推測不可 | 比較的新しい |
| Snowflake ID | Twitter発の分散ID | ソート可能・高性能 | 実装が複雑 |
現代のベストプラクティス
- 代理キー（ID）を内部のPKとして使用
- 業務キー（メールアドレス等）は
UNIQUE制約付きの別カラムに - 公開URLには連番IDより推測不可能なUUIDを使用
歴史と背景
- 初期のDB設計：自然キーを主キーとして使うのが一般的だった
- 1990〜2000年代：大規模システムでの自然キーの問題が顕在化し代理キーが普及
- 現在：ULIDやSnowflake IDなどの分散IDの標準化が進む