サロゲートキーと「とりあえずID」の違い - 設計者の発言

サロゲートキー（代理キー）は慎重になされる限り、有用なテクニックである。いっぽう、すべてのテーブルに機械的にIDを置く「とりあえずID（IDリクワイアド）」の設計スタイルでは、複雑なデータ要件を扱った途端にひどい目にあう（とくに保守担当者が）。両者の違いをしっかり理解しておこう。 何でもいいのだが、ここでは生産管理システムで見かけそうなシンプルなモデルを使って説明しよう（図１）。「作業区・品目」は、それぞれの作業区で生産可能な品目の組み合わせと、その品目を扱った際の生産性（時間あたり生産数）の管理簿である。 ＜図１＞ [工程]工程id,工程名,扱い単位 ＋ ￣￣￣ ｜ 001 切削 個 ｜ 002 加工 ｍ ｜ └―∈[作業区]工程id,行番,作業区名,標準生産性 ＋ ￣￣￣￣￣￣ ｜ 001 01 切削１号 1000/hr ｜ 001 02 切削２号 2

[JHashimoto]

"とりあえずIDを主キーとする。運よく図２と似た形になったとしても、なにしろ論理要件が了解されていないため、ユニーク制約や更新不可制約の配慮があちこちで漏れる。"

[nobeans]

サロゲートキーを導入するとどうして図2のようになってしまうのかが理解できてない。図2の[作業区・品目」の工程idは不要なように思うのだけど...

[koyancya]

「しようぜよ」カッコイイ "ようするに、どんな実装上の制約があろうとまともにデータモデリングしようぜよ"

[t-wada]

おおっ! 『SQL アンチパターン』が渡辺幸三さんまでリーチしている!! 解説ありがとうございます! #sqlap

[rryu]

サロゲートキーというからにはaltenate keyもあるはずなので、ユニーク制約は｛id｝,｛作業区id,工程id,品目id｝の2つになるはず。

[popio]

読んでるけどなかなか頭に入ってこない

[tsucchi1022]

うーん、この場合自然キーじゃないからどっちでも良いと思うんだけど、前者と後者でアプリの更新の仕方がぜんぜん変わってくるから一概にどっちがいいとはいえないんじゃないかと思うんだけど、よくわかんない