今日も元気に真人間

好き: 中日 、アニソン 、中本 、IT 、乃木坂46(乃木坂って、どこ?、乃木坂工事中)

サロゲートキーについて

色々と調べたので整理してまとめておく。

 

 

ナチュラルキーとサロゲートキー

一旦普通に設計して、基本的には主キーっぽいものが複数キーの組み合わせ(ナチュラルキー)になった場合の話。

複合主キーを嫌って、業務的に意味のないIDを振ってそっちを主キーとするのがサロゲートキー

 

特に、サロゲートキーを「テーブル名_id」とかにせず単に「id」としてしまい、何でもかんでもこのようなキー設計にすることを、『SQLアンチパターン』では「IDリクワイアド」と呼んでいるらしい。

 ただ、これに関しては割と賛否が分かれているようだ。

 

 

■複合主キーのここが嫌

・テーブル間の結合度が低くなる

外部キーなんかになってると修正が入ったときにそのテーブル自体の他に参照しているテーブルも修正する必要がある。

(これは複合キーでなくても、ナチュラルキーに言える特徴。)

 

・JOINなど、SQL文が煩雑になる

 

・主キーの範囲指定を行う際に、指定できない

キー1が1~10かつキー2が50~100、のような指定は一般にはできないことが多い。

 

(・主キーを一律サロゲートキーにしてキー名称を「ID」とか「No」とかで統一すると、フレームワークとか次第では業務ロジックの実装などで統一的に処理を記述できる→本当か?)

 

 

サロゲートキーのここが問題

・直感的にキーの意味が分かりにくい

複合主キーの方が、エンティティの意味合いやレコードの区別が理解しやすい。

 

・余計な項目が増える

正直容量的な意味では大した問題ではないどころか、設計が整理されてむしろ減る場合もあるとか。

 

・結局元々複合主キーだったものにはユニーク制約を入れる必要がある

サロゲートキーを設定したところで、元々複合主キーだったものは重複してはいけないはずなので、これらに対して制約は必要。そうなると実質主キーが2つあるようなものなので、無駄にも思える。

 

・外部参照してるときに参照先のエンティティが何者か分かりにくい

複合主キーなら属性名見るだけである程度分かるが、結合しないと分からなくなってしまう。

 

・JOINのときにUSINGが使えない

 

・主キー以外に設定できないものがあるかもしれない

元々複合キーだったものに対して、インデックスなどの何かしらを設定したいときに、DBMSによっては主キーに対してしか設定できない内容がある場合もあるらしく、その場合にはパフォーマンスに影響する。

 

・データ移行のときに困る

以降前後でデータ値が大きく変わってたりすると困るらしい。

 

 

個人的には、直感的な理解のしやすさを取るか、テーブル間の結合度の低下を取るかのどっちかといったところ。

 

 

サロゲートキーの実現方法

〇シーケンスオブジェクト

blog.engineer-memo.com

 

〇オートインクリメント

qiita.com

 

 

■参考資料

sutekina121.com

 

d.hatena.ne.jp

 

nemorine.hateblo.jp

 

d.hatena.ne.jp

 

makopi23のブログ SQLアンチパターン読書会 「IDリクワイアド」に参加しました

 

サロゲートキーと複合主キー | DBFlute