Open1
DB設計個人的メモ
ID_157PKの設計時に通すべき思考回路
自然キー vs 代理キー
- 自然キー・コードの特徴
- ユーザーの目に触れる
- ビジネスロジックによって決定される
- 代理キー（人工キー）・ID派
- ユーザーの目に触れない
- 自動採番・UUIDなどで実装される
自然キーと代理キーのどちらを利用するべきかは、次のような観点から判断する。
- 使用しているORMラッパーによる制約
- システムの寿命内にビジネス側でコードのフォーマットが変更されうるか / 変更された場合の影響範囲
- 例えば、IPv6アドレスのフォーマットが変更される可能性は限りなく低く、一意性もあるので自然キーとして利用できる
- （例：学生証番号J + 科類に応じた一桁の数字 + 入学年度下二桁 + 同年度・同科類の中での何らかの連番4桁）のようなコードは、科類の数が10以上になったり2100年台になった場合に変更される可能性がある。（最も、システムの寿命として10年程度を想定している場合は無問題だろう。）
- 複数のシステムに跨って利用されうるか
- レコードの部分集合だけが他のシステムで利用される場合は、IDは整数値の連番よりuuidを利用した方が直観的
また、代理キーを用いる場合は自然キーとなりうる値に一意性制約を設けることを忘れてはならない。
複合主キー vs 代理キー
- 複合FKは大変
- 複合主キーを持つテーブルを他のテーブルで参照する場合には、複合FKが生まれるが、これはSQLを書くときのバグを誘発しやすい
これらの問題には宗教問題的な側面もある。
【参考】
『漢(おとこ)のコンピュータ道 IDの設計についてのさらに突っ込んだ議論』http://nippondanji.blogspot.com/2013/12/id.html
『M.I.のプログラミング・メモ 商品コードを主キーにするべきではない理由』
『DBFlute サロゲートキーと複合主キー』