SQLアンチパターン「IDリクワイアド」の再検討 - 極北データモデリング

SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人 クリック: 698回この商品を含むブログ (46件) を見る話題のSQLアンチパターンの目次に「アンチパターン：すべてのテーブルにID列を用いる」とあるのを見て、大胆にもサロゲートキーを否定しているのかと思って読んでみたが、どうも主張がはっきりしない。論点が尽くされていないような... 「SQLアンチパターン」の主張 第3章には以下のようなことが書いてある。 「IDリクワイアド」アンチパターン IDリクワイアドは「すべてのテーブルに"id"という列名の無意味な連番の列を追加し、PRIMARY KEY制約を付与する」というパターンのこと。 何がいけないのか 自然キーにUNIQUE制約を付けないなら、自然キーの重複を

[s-tomo]

テーブルごとに1から順にID振ってるから論点が曖昧になるんだ。GUIDにしよう（多分そういう話じゃない）

[nakag0711]

人工キー論争未だ決着つかず

[JHashimoto]

"個人的には、IDリクワイアドについては「DBMS実装の事情を考えずにID列を必ず主キーにする」点が問題だと思う。"

[FTTH]

何も考えないでID振って、必要なら複合UNIQUE振る派。（DB設計自分ですること基本的に無いけど）

[zetamatta]

サロゲートキー(ビジネス上の意味を持たない連番などを用いた主キー)についての議論

[te2u]

idは行を一意に、かつ1次元で表現できる。だから「"id"という列名の無意味な連番」とは考えていない。必要ないのは履歴系かな。/自然キーは、外部からの変更の影響をもろに受けるので、できる限り主キーにはしない。

[tsucchi1022]

まだこの本読んでないんだけど、ナチュラルの主キー認めた上で、id列ダメって言ってるの？それは違う気がするな。ナチュラル駄目っていうのなら分かるけど。。。

[t-wada]

"実際に工数がかさんでいるのなら、拒否反応を無視してよいわけがない" "「主キーが必要な理由」になっていない(ぜんぶUNIQUEインデックスで実現できるから)" "主キーにはDBMSによって変な制約が付くことがある" #sqlap

[takuya_1st]

いやぁ。連番便利だよ本当に。複合Keyなんてユーザーインターフェースですよ。（複合Keyはユーザーが見て分かりやすいためにワザワザつけてあげてる印象）

[k-holy]

論理モデル的に明らかに不要な場合を除いてサロゲートキーは使うけど、履歴問題についてはもにょもにょしつつ転記してる…"実装の事情"はどちら側にもあるものなのだなぁと。

[dagama]

自然キーで事足りるのにサロゲートキーでさらにINDEX領域食うとか容量無駄遣いだろとか／もちろん開発で楽をするためにIDとUNIQUEインデックスで片付けることはある

[koyancya]

サロゲートキーはあれば便利だし、あっても邪魔にならない。と、今のところ思っている。using 使えるように hoge_id にした方が良さそうというのは同意。ORM の規約をそのように変更できればいいが。

[okoppe8]

「細けえなぁと思われるかもしれないが、前述の通り主キーにはDBMSによって変な制約が付くことがあるので、ある程度注意して使わなくてはならない。」

[ktakemoto]

アイデーリクワイアド

[rryu]

結合テーブルのカラムすべてが複合キーかつユニークという「主キーしかないんじゃね?」みたいな時と書いてあったような。外部キー群の直積に近い行数が作られる場合はIDがあふれる可能性があるので無い方が良い。

[rhosoi]

あ、俺SQLアンチパターンまだ読んでないや・・・(´∀｀)

[gotouma]

主キーを構成する列でなくてはパーティショニングのキーにできないDBMSなどを使うのであれば、自然キーを主キーにしておかないと、パフォーマンス問題に対する打ち手を失うことになるだろう。