はじめに
DB 設計における宗教戦争のひとつ、ナチュラルキー VS サロゲートキーに関しての個人的な見解です。
改訂履歴
- 2026/05/21 : 初版公開。
本文
1. 結論
僕の担当している FA システムの領域では、ナチュラルキーの方が適しているケースが多いと考えています。実際、僕の観測範囲でも、ナチュラルキーが採用されている設計が大半でした。他のドメインにはそれほど明るくありませんが、一般的な業務システムであれば、サロゲートキー + UNIQUE 制約の構成も現実的な選択肢だと思います。
2. 比較
2-1. ナチュラルキー
ナチュラルキーとは、現実世界で元々一意性を持つ値をそのまま主キーにする方式です。
2-1-1. 例
- メールアドレス
- 書籍コード (ISBN)
- 国コード (ISO 3166)
- 社員番号
2-1-2. メリット
- データの意味とキーが一致しているため、直感的である。
- テーブルを参照した際に、主キーだけで対象データを識別しやすい。
- 業務上の識別子をそのまま DB の一意性制約として利用できる。
- サロゲートキーと業務キーを別々に管理する必要がない。
2-1-3. デメリット
- 業務ルールの変更に弱い。
- 複合キー化しやすく
JOINや外部キーが複雑になりやすい。 - キーのデータ長が大きい場合、インデックスや外部キーのサイズに影響する。
- 業務上の識別子をそのまま利用するため、その値の変更が複数テーブルに波及する可能性がある。
2-2. サロゲートキー
サロゲートキーとは、ビジネス上の意味を持たない、システムが生成する人工的な一意の値を主キーにする方式です。
2-2-1. 例
user_idorder_id
2-2-2. メリット
- 業務ルールの変更による影響を受けにくい。
- 外部システムの識別体系に依存しない。
- 外部キーを固定長・小サイズの値にしやすい。
- 複合主キーを避けやすい。
- DB 上の識別子と業務上の識別子を分離できる。
2-2-3. デメリット
- 主キーだけでは、その値が何を意味するのか分からない。
- 業務上の一意性を担保するために、別途
UNIQUE制約が必要になる。 - 主キーと業務キーという 2 つの識別体系を管理する必要がある。
- DB のためだけに人工的な ID を追加することになり、ドメインによっては過剰設計になる場合がある。
3. FA システムの特殊性
FA システムの特徴として、設備・ライン・品目・工程といった「現実世界の構造」が強く固定されている点が挙げられます。これらはソフトウェア側の都合で頻繁に変わるものではありません。変更が発生する場合も、ハードウェアの更新や生産ラインの再設計など、極めてコストの大きい物理的イベントに紐づいています。
また FA システムはライフサイクルが長く、最初から 10 〜 20 年は稼働する前提で計画されることが一般的です。そのため、データモデルの前提となる識別体系や生産フローも、初期段階で明確に定義されていることが多いです。つまり FA システムは、ナチュラルキー最大の弱点である「変更リスク」が極めて少なく、そのメリットを最大限に享受できるドメインだと言えると思います。
4. 参考
おわりに
結局、ドメインと要件次第だよねって思います。