はじめに
DB 設計における宗教戦争のひとつ、ナチュラルキー VS サロゲートキーに関しての個人的な見解です。
改訂履歴
- 2026/05/21 : 初版公開。
結論
僕の担当している FA システムの領域では、ナチュラルキーの方が適していると考えています。実際、僕の観測範囲でも、ナチュラルキーが採用されている設計が大半でした。
他のドメインにはそれほど明るくありませんが、一般的な業務システムであれば、サロゲートキー + UNIQUE 制約の構成も現実的な選択肢だと思います。
メリット・デメリットの比較
1. ナチュラルキー
ナチュラルキーとは、現実世界で元々一意性を持つ値をそのまま主キーにする方式です。
例
- メールアドレス
- 書籍コード (ISBN)
- 国コード (ISO 3166)
- 社員番号
メリット
- データの意味とキーが一致しているため、直感的である
- JOIN 時に余計な変換が不要で SQL がシンプルになる
- 重複データの発生を構造的に防げる
デメリット
- 業務ルールの変化に弱い
- 複合キー化しやすく JOIN や外部キーが複雑化する
- キーのデータ長が肥大化しやすく、インデックスのパフォーマンスに影響する場合がある
2. サロゲートキー
サロゲートキーとは、ビジネス上の意味を持たない、システムが生成する人工的な一意の値を主キーにする方式です。
例
- user_id
- order_id
メリット
- 業務ルールの変更による影響を受けない
- 外部システムに依存しない
- 外部キーは常に固定値になり、参照関係が安定する
- 数値や短い固定長のキーは、インデックスの効率が良い
- 複合キーを避けられるため、シンプルな構造を保てる
デメリット
- ビジネス上の一意性が DB からは見えず、ドキュメントなどでの補足が必要になる
- ビジネス上の一意性を担保するために、別途 UNIQUE 制約を設定する必要がある
- テーブル構造が冗長な構造になりやすい
- いわゆる YAGNI (You Aren't Gonna Need It) 原則に反する場合がある ※ 完全に個人の感想かも
FA システムの特殊性
FA システムの特徴として、設備・ライン・品目・工程といった「現実世界の構造」が強く固定されている点が挙げられます。
これらはソフトウェア側の都合で頻繁に変わるものではありません。変更が発生する場合も、ハードウェアの更新や生産ラインの再設計など、極めてコストの大きい物理的イベントに紐づいています。
また FA システムはライフサイクルが長く、最初から 10 〜 20 年は稼働する前提で計画されることが一般的です。そのため、データモデルの前提となる識別体系や生産フローも、初期段階で厳密に設計されています。
つまり FA システムは、ナチュラルキー最大の弱点である「変更リスク」が極めて少なく、そのメリットを最大限に享受できるドメインだと言えます。
参考
おわりに
結局、ドメインと要件次第だよねって思います。