È comunemente accettato che le chiavi primarie debbano essere immutabili (o il più stabili possibile poiché l'immutabilità non può essere applicata nel DB). Anche se non c'è nulla che ti impedisca di aggiornare una chiave primaria (tranne il vincolo di integrità), potrebbe non essere una buona idea:
Dal punto di vista delle prestazioni:
- Dovrai aggiornare tutte le chiavi esterne che fanno riferimento alla chiave aggiornata. Un singolo aggiornamento può portare all'aggiornamento di molte tabelle/righe.
- Se le chiavi esterne non sono indicizzate (!!) dovrai mantenere un blocco sulla tabella dei figli per assicurarne l'integrità. Oracle manterrà il lucchetto solo per un breve periodo, ma è comunque spaventoso.
- Se le tue chiavi esterne sono indicizzate (come dovrebbero essere), l'aggiornamento porterà all'aggiornamento dell'indice (cancella+inserisci nella struttura dell'indice), questo è generalmente più costoso dell'aggiornamento effettivo della tabella di base.
- Nelle tabelle ORGANIZATION INDEX (in altri RDBMS, vedere chiave primaria raggruppata), le righe sono ordinate fisicamente in base alla chiave primaria. Un aggiornamento logico risulterà in un'eliminazione fisica + inserimento (più costoso)
Altre considerazioni:
- Se questa chiave è referenziata in qualsiasi sistema esterno (cache dell'applicazione, un altro DB, esportazione...), il riferimento verrà interrotto al momento dell'aggiornamento.
- inoltre, alcuni RDBMS non supportano l'AGGIORNAMENTO CASCADE, in particolare Oracle.
In conclusione, durante la progettazione, è generalmente più sicuro utilizzare una chiave surrogata al posto di una chiave primaria naturale che dovrebbe non cambiare, ma potrebbe eventualmente dover essere aggiornata a causa di requisiti modificati o persino di errori di immissione dei dati.
Se devi assolutamente aggiornare una chiave primaria con la tabella figli, consulta questo post di Tom Kyte per una soluzione.
