サロゲートキーは強制されるべきものではない - 設計者の発言

複合主キーに代えてサロゲートキー（単独主キーの代替キー）を導入すべきかどうか。それはDB設計上の重要な判断事項である。なにしろレコードのアイデンティティである主キーの設定にかかわる問題だ。さまざまなメリットやデメリットを考慮してそれは判断される。その結果、サロゲートキーを導入することもあるし、しないこともある。 ところが、サロゲートキーを強制する（あるいはサロゲートキーを導入しないと開発しにくい）開発基盤がいくつか存在する。具体的には、全テーブルの識別子が"ID"等のフィールド名を持つ単独主キーであることが求められたりする。私に言わせれば、そういう開発基盤は「大盛を強制する牛丼屋」である。メニューにあるはずの「並」を頼むと、あれこれイヤガラセをされる牛丼屋。 この問題に関連して、「サロゲートキーを使わなかったから、ひどい目にあった」という開発者の声を聞いたことがあるかもしれない。心配はいら

[tsubasa373]

現在、悩み中。

[ledsun]

全然関係ないけど素人に関連を理解させるうまい表現はないのかな？マスタとトランザクションは台帳と伝票で説明できるんだけどな。

[lizy]

テーブルサイズが膨らむ以外のデメリットが特に思いつかない。複合主キーというのは、データの性質が偶然そうだっただけの話で、主キーにするべきとは別問題のような

[udzura]

何かこの辺の議論昔勉強したなあ……覚えてないや

[otchy210]

泥臭い話だけどさ、運用フェーズで DB を直接いじらなきゃなんない事があるわけよ。そんなとき複合主キーしかないと面倒だし間違いやすいので、サロゲートキー肯定派です。

[rhosoi]

「サロゲートキーでもオーケー、複合主キーのままでもオーケー。そんな開発基盤であってほしい。」

[daisuke-m]

とても勉強になる！

[t-wada]

"データベースシステムには「複雑さの保存則」のようなものがある。「データ構造の複雑さ」と「データ処理の複雑さ」の総量は一定である" なるほどと思う。そして結論にはとても同意する。

[dagjmpd]

サロゲートキーは強制されるべきものではない

[sugibuchi]

データベースシステムの「複雑さの保存則」というのは至言。要するに同じ複雑さがDBスキーマとして宣言的に記述されているかアプリケーションロジックとして手続き的に記述されているかの違いでしかない。

[sh2]

サロゲートキーの使用は開発基盤で制約せず設計者が選択できるべき、データ構造の複雑さとデータ処理の複雑さの総量は一定

[torazuka]

"ＤＢ構造が本来担うべき「意味」"の範囲をどう考えようか。/ OOとDOAをそれぞれ自覚的に適用すべきというのは、たしかに。訓練しよう。