}}適切な情報に変更エントリーの編集エントリーの編集は全ユーザーに共通の機能です。ガイドラインを一読の上ご利用ください。非公開にするキャンセルtwitterアカウントが登録されていません。非公開にするキャンセルtwitterアカウントが登録されていません。いう事を無視して責められないための理論的正しさを追い求めてるだけに見えるので、もはやどうでもいい感が強い。サロゲートキーつかうときに、履歴問題はついてまわるんだけど、利点欠点半々の印象。いう場合はコードが変わるのは許さんって言っちゃえばいいの。業務に密接に関係するコードなんてものが存在するのが悪いんだから、ユーザにもちょっとはシステムに最適化させるべき。業務が変わらなくても設計は変わるので、データの関連性はサロゲートキー派。個体識別と呼び名は別だと思うし、内部実装は好きにできるようにさせろよってのがある。アプリケーションのリポジトリとして使う分には、エンドユーザから見える・エンドユーザが入力可能な値はキーにしたくないので可能な限り(外部から隠蔽された)サロゲートキー使用派。BigTableだとサロゲートキーはパフォーマンスの劣化や遅延による障害の原因につながりやすいので避けてはいるけど、しかし場合によりけりかなぁ...。従属テーブルのサロゲートキーは要らない場合が多いというだけで外部キーとして主テーブル側のサロゲートキーを入れることまでは否定していないような。今では必ずそうしてる。昔は5種複合主キーとかでよく地獄を見せてもらいました。僕は自然キーよりサロゲートキー使ったほうが良い派で、サロゲートキー入れる場合は自然キーをとりあえずUKにしてるなー。いう事を無視して責められないための理論的正しさを追い求めてるだけに見えるので、もはやどうでもいい感が強い。「SQLアンチパターン」第3章の記述を総合すると、著者はサロゲートキーについて以下のように考えていると思う。自然キーの一意性・不変性が当てにならない場合に「自然キーの変更の影響を受けないようにする」という目的でサロゲートキーを導入する。自然キーの重複を防ぐために、自然キーにUNIQUEインデックスを振ることを推奨する。自然キーの代わりにサロゲートキーを外部キーにする。Reserved.設定を変更しましたx。