DOA派からサロゲートキーが嫌われる理由
今、複合キー論が熱い！
渡辺幸三氏の「設計者の発言」で、サロゲートキーがDOA派から嫌われている理由がわかった。
理由の一つは、サロゲートキーの導入によって、もともとある複合キーの実装が忘れられがちになる。だから危ない、ということだった。
ということは、
- 複合キーに忘れずに unique index を付けておけばよい
- サロゲートキー自体に問題はない
ということだな。
代理キーは「スタイル」ではなく「テクニック」
http://watanabek.cocolog-nifty.com/blog/2006/09/post_d032.html
じつは「サロゲートキーにこだわるモデリングスタイル」には、目立たないがやっかいな
問題がある。複数のidが複合してユニーク制約を構成している事実を見落としやすい点だ。
...
実際、同業者の友人が最近かかわったそのような事例では、各テーブルに必要なはずの
ユニーク制約の８割が見落とされていたそうだ。相当にデータモデリングや業務知識に
通じた技術者にまかせないと怖い。
結論が反対
IDとサロゲトーキーが違う概念だということは分かってるけど、上の引用では実質同じものを指していると考えると、羽生氏と渡辺氏は
羽生氏：ID全面導入は、ルールを単純化し、余計なTipsを生まないことで、DB設計を簡単にする
渡辺氏：ID全面導入は、コード体系の分析を手抜きできてしまうので、相当分かってる人がやらないとやばい
と反対の結論になっている。
IDを導入してもコード体系の分析が軽減されるわけではないので、IDによって設計が簡単になるというのは、よく分からない。
一方で、そんなに危険なものとも思えない...
今自分はどうやっているか
あんまり意識したことがなかったが、今自分はどうやってIDを振っているか。
並べて書いてみると、自分が何をルールとしているのか、よくわからない。
ルールがわからないのに従っている感覚がある。気持ち悪い。
大抵はIDを振る
resourceには無条件にIDを振る。
eventでも、行単位で名前のあるものにはIDを振る。例えば { 科目ID, 教官ID } で一意性を保障する「講座」テーブルがあったら、講座IDが必要。
これは別に理論的な背景があるわけではなくて、純粋にアプリケーションの都合。
HTMLのコンボボックスで「講座」を選択するUIを作ったら、複合キーをPOSTする仕組みを作るのがおっくうなので単一のキーが欲しいとか、その程度の理由。
たまにIDを振らない
MO(=多値を外出ししたテーブル)にはIDを振らない。例えば社内システムで「社員がメールアドレスを好きなだけ持てる」という場合、社員マスタに社員メールアドレステーブルを外付けする。これがMO。
社員メールアドレステーブル = { 社員ID, メールアドレス }
この時、社員メールアドレステーブルは主キーなしにする。社員IDとメールアドレスに個別にインデックスを付ける。どちらも unique index にはしない。
あと、delete & insert で更新する対照表にはIDを振らない。社員マスタとプロジェクトマスタの間の対照表「社員所属プロジェクトテーブル」とか。これも主キーなし。unique indexは付ける。
