Il est communément admis que les clés primaires doivent être immuables (ou aussi stables que possible puisque l'immuabilité ne peut pas être imposée dans la base de données). Bien que rien ne vous empêche de mettre à jour une clé primaire (à l'exception de la contrainte d'intégrité), ce n'est peut-être pas une bonne idée :
D'un point de vue performances :
- Vous devrez mettre à jour toutes les clés étrangères faisant référence à la clé mise à jour. Une seule mise à jour peut entraîner la mise à jour de nombreux tableaux/lignes.
- Si les clés étrangères ne sont pas indexées (!!), vous devrez maintenir un verrou sur la table des enfants pour garantir l'intégrité. Oracle ne maintiendra le verrou que pendant une courte période, mais cela reste effrayant.
- Si vos clés étrangères sont indexées (comme il se doit), la mise à jour entraînera la mise à jour de l'index (supprimer+insérer dans la structure de l'index), ceci est généralement plus coûteux que la mise à jour proprement dite de la table de base.
- Dans les tables ORGANIZATION INDEX (dans d'autres SGBDR, voir clé primaire en cluster), les lignes sont physiquement triées par clé primaire. Une mise à jour logique entraînera une suppression physique + insertion (plus coûteuse)
Autres considérations :
- Si cette clé est référencée dans un système externe (cache d'application, autre BD, export...), la référence sera rompue lors de la mise à jour.
- De plus, certains RDBMS ne prennent pas en charge CASCADE UPDATE, en particulier Oracle.
En conclusion, lors de la conception, il est généralement plus sûr d'utiliser une clé de substitution au lieu d'une clé primaire naturelle qui est censée ne pas changer - mais qui peut éventuellement devoir être mise à jour en raison de modifications des exigences ou même d'une erreur de saisie de données.
Si vous devez absolument mettre à jour une clé primaire avec une table enfants, consultez cet article de Tom Kyte pour une solution.
