主キーは不変である必要があります （または 可能な限り安定している はDBで不変を強制できないため）であることが一般的に同意されています。主キーの更新を妨げるものはありませんが（整合性制約を除く）、それは良い考えではありません。
パフォーマンスの観点から：
- 更新されたキーを参照するすべての外部キーを更新する必要があります。 1回の更新で、大量のテーブル/行が更新される可能性があります。
- 外部キーがインデックス付けされていない場合（!!）、整合性を確保するために子テーブルのロックを維持する必要があります。 Oracleは短時間だけロックを保持しますが、それでもなお怖いです。
- 外部キーにインデックスが付けられている場合（必要に応じて）、更新によりインデックスが更新されます（インデックス構造で削除+挿入）。これは通常、ベーステーブルの実際の更新よりも高価です。
- ORGANIZATION INDEXテーブル（他のRDBMSでは、クラスター化された主キーを参照）では、行は主キーによって物理的にソートされます。論理的な更新により、物理的な削除と挿入が行われます（より高価です）
その他の考慮事項：
- このキーが外部システム（アプリケーションキャッシュ、別のDB、エクスポート...）で参照されている場合、参照は更新時に壊れます。
- さらに、一部のRDBMSはCASCADE UPDATE、 特にOracle をサポートしていません。
結論として、設計中、一般的に、変更しないはずの自然なプライマリキーの代わりに代理キーを使用する方が安全です。
子テーブルを使用して主キーを絶対に更新する必要がある場合は、 解決策についてTom Kyteによるこの投稿 を参照してください。
主キー属性は、テーブルの他の属性と同様に更新可能です。多くの場合、安定性はキーの望ましい特性ですが、絶対的な要件ではありません。キーを更新することがビジネスの観点から理にかなっている場合、そうすべきでない根本的な理由はありません。
限りすることができます
- 値は一意です
- 既存の外部キーに違反はありません
リレーショナルデータベース理論の観点からは、プライマリキー間に重複がなく、プライマリのいずれにもNULL値を入れない限り、テーブルのプライマリキーの更新にまったく問題はないはずです。キー列。
簡単な答え：はい、できます。もちろん、新しい値が既存の値と一致せず、他の制約が満たされていることを確認する必要があります（duh）。
正確に何をしようとしていますか？
特定の状況では可能です。
しかし、あなたがこれを考慮するという事実は、あなたのアーキテクチャに何か問題があるという強い兆候です。主キーは純粋に技術的なものであり、ビジネス上の意味はまったくありません。したがって、それらを変更する必要はないはずです。
トーマス