Float on the flow

とあるエンジニアのブログ。「ゆったり・しっかり」がモットー。

DBモデリングの話

最近サロゲートキーとか複合主キーの話がアツい*1


自分は基本的にはどっちでもいいと思っている日和見派なので、
文脈によって使い分けることにしよう。
(そのほうがメリットデメリットを理解できそうだし。)


今のところ

  • 会社では、複合主キー(それ前提で開発手法が標準化されてるから)
  • 個人的には、サロゲートキーRails使用ならこうしたほうが便利)

という使い分けだな。


関連リンク(多いので、今日見たとこだけ)
http://d.hatena.ne.jp/tgk/20060906#1157553270
http://d.hatena.ne.jp/bottleneck/20060906/1157545775
http://d.hatena.ne.jp/arn/20060906#p3
http://d.hatena.ne.jp/niraikanaibird/20060904#1157359866
http://d.hatena.ne.jp/arn/20060904#p2



ところで、よく見たら
http://watanabek.cocolog-nifty.com/blog/2006/09/post_d032.html
のコメントで、わたなべさん自身が

必要なユニーク制約が抜け落ちていないのであれば、
問題はありません。けれどもそれを狙うのであれば
「複合キーにもとづくデータモデリング」を実施
したうえで形式的な調整を施すという手順を踏んだ
ほうがよほど仕事が早いと思うわけです。

とおっしゃっている。


ので、自分としては

  • 基本テーブルはID(サロゲートキー)で考える
  • 複合的なテーブルは複合キーで考えて、そこにIDとユニーク制約をつける

という2段構えで臨むか。

*1:まだ旬は過ぎてないよね?w