SQLアンチパターン「健忘症的サロゲートキー」の提案 - 極北データモデリング

SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人 クリック: 698回この商品を含むブログ (46件) を見る本書の著者はサロゲートキーに対して消極的なのだから、「サロゲートキーの使い方がおかしい」とか言うのはお門違いなのかもしれないが... 健忘症的サロゲートキー 「SQLアンチパターン」第3章の記述を総合すると、著者はサロゲートキーについて以下のように考えていると思う。 自然キーの一意性・不変性が当てにならない場合に「自然キーの変更の影響を受けないようにする」という目的でサロゲートキーを導入する。 自然キーの重複を防ぐために、自然キーにUNIQUEインデックスを振ることを推奨する。 自然キーの代わりにサロゲートキーを外部キーにする。自然キーは他のテーブルに転

[habuakihiro]

このネタは、利用価値を創出し"続けられる"システム＞＞＞（越えられない壁）＞正しいDB設計　という事を無視して責められないための理論的正しさを追い求めてるだけに見えるので、もはやどうでもいい感が強い。

[skyriser]

サロゲートキーがジャスティスなのかどうかは永遠に決着が着かない問題だと思う

[yojik]

サロゲートキーつかうときに、履歴問題はついてまわるんだけど、利点欠点半々の印象。(最初から履歴を意識した設計をおこなうしかないが、むしろそれを強制されるから良いみたいな…)

[dagama]

こういう場合はコードが変わるのは許さんって言っちゃえばいいの。業務に密接に関係するコードなんてものが存在するのが悪いんだから、ユーザにもちょっとはシステムに最適化させるべき。

[knjname]

業務が変わらなくても設計は変わるので、データの関連性はサロゲートキー派。個体識別と呼び名は別だと思うし、内部実装は好きにできるようにさせろよってのがある。

[ka-ka_xyz]

アプリケーションのリポジトリとして使う分には、エンドユーザから見える・エンドユーザが入力可能な値はキーにしたくないので可能な限り（外部から隠蔽された）サロゲートキー使用派。

[akitsukada]

"過去の受注の商品コードを復元できない"のが困るんだったら受注明細には事実として受注時点での商品コードを残しておくべきでないかな／「トランザクション上の自然キーは過去の事実だから云々」がそれかな

[quabbin]

BigTableだとサロゲートキーはパフォーマンスの劣化や遅延による障害の原因につながりやすいので避けてはいるけど、しかし場合によりけりかなぁ…。

[rryu]

従属テーブルのサロゲートキーは要らない場合が多いというだけで外部キーとして主テーブル側のサロゲートキーを入れることまでは否定していないような。

[ku__ra__ge]

サロゲートキー側の反論も聞いてみたい

[sifue]

今では必ずそうしてる。昔は5種複合主キーとかでよく地獄を見せてもらいました。

[tsucchi1022]

僕は自然キーよりサロゲートキー使ったほうが良い派で、サロゲートキー入れる場合は自然キーをとりあえずUKにしてるなー。

[t-wada]

"自分で立てた前提を忘れている" "過去の事実を復元できない" "「自然キーとサロゲートキーのどっちがよいか」みたいな話はもう聞きたくねえんです" "もうちょっと解像度の高い議論があればぜひ伺いたい" #sqlap