主キーは不変である（またはDBで不変性を強制できないため、可能な限り安定している）必要があることが一般的に合意されています。主キーの更新を妨げるものは何もありませんが（整合性制約を除く）、それは良い考えではないかもしれません：
パフォーマンスの観点から：
- 更新されたキーを参照するすべての外部キーを更新する必要があります。 1回の更新で、潜在的に多数のテーブル/行が更新される可能性があります。
- 外部キーのインデックスが作成されていない場合（!!）、整合性を確保するために子テーブルのロックを維持する必要があります。オラクルは短時間だけロックを保持しますが、それでもこれは恐ろしいことです。
- 外部キーにインデックスが付けられている場合（必要に応じて）、更新によってインデックスが更新されます（インデックス構造に削除+挿入）。これは通常、ベーステーブルの実際の更新よりもコストがかかります。
- ORGANIZATION INDEXテーブル（他のRDBMSでは、クラスター化された主キーを参照）では、行は主キーによって物理的にソートされます。論理的な更新により、物理的な削除と挿入が行われます（より高価です）
その他の考慮事項：
- このキーが外部システム（アプリケーションキャッシュ、別のDB、エクスポートなど）で参照されている場合、更新時に参照が壊れます。
- さらに、一部のRDBMS、特にOracleはCASCADEUPDATEをサポートしていません。
結論として、設計時には、変更されないはずの自然な主キーの代わりに代理キーを使用する方が一般的に安全ですが、要件の変更やデータ入力エラーのために最終的に更新する必要がある場合があります。
>子テーブルを使用して主キーを更新する必要がある場合は、解決策についてTomKyteによるこの投稿を参照してください。