Discussion :

[dcollart]

Bonjour,

je suis amené à devoir mettre à jour la clé primaire d'une table (clé composée d'un seul champs). Existe-t-il un moyen de mettre à jour cette clé tout en mettant à jour automatiquement les champs des tables lui faisant référence.

Par exemple :

table t1 avec clé primaire PK1
table t2 avec clé primaire PK2 et clé étrangère FK2 faisant référence à PK1

Est-il possible de mettre à jour PK1 tout en mettant à jour automatiquement FK2 ?

Je pensais à une solution ressemblant à :

UPDATE t1 SET PK1 = 'new value' WITH CASCADE CONSTRAINT;

Est-ce possible ?

Merci et bonne journée.

[coco-sup]

il me semble qu'au niveau de la clé étrangère tu n'a que 2 options au moment de la création... ON DELETE SET NULL et ON DELETE CASCADE mais cela ne concerne que la suppression d'un clé primaire...

Sinon l'utilisation d'un trigger pourrait sans doute résoudre ton problème je pense...

[remi4444]

Non ce n'est pas possible à ma connaissance. Modifier une clef primaire d'un point de vue logique, c'est supprimer un élément et en recréer un autre, et tu ne peux pas supprimer un élément sur lequel il y a des références.
Si c'est une opération ponctuelle, le plus simple est de rendre innactives les clefs étrangères le temps de faire les modifications sur toutes les tables.

[Yorglaa]

je suis d'accord avec remi4444.

en théorie on ne doit jamais modifier une clef primaire !!
dans quel contexte est-ce que tu es appellé à modifier une clef primaire ?

[fsmrel]

Bonsoir,

Du point de vue théorique, rien n'interdit de changer la valeur d'une clé primaire avec effet CASCADE sur une clé étrangère. Le standard SQL confirme. Si Oracle n'a pas retenu cette option, on peut supposer que c'est pour copier DB2 (mais je n'en ai aucune preuve !) Si DB2 interdit la modification en cascade, c'est pour une raison surprenante. Il est écrit noir sur blanc dans "IBM Database 2 Referential integrity usage guide" - Document number GG-243312-0, June 1988, page 48 : "The reason for this restriction is philosophical". Comme si un SGBD devait faire de la philosophie, on aura tout vu !

Maintenant, la sagesse veut qu'une clé primaire soit un invariant dans la base de données, c'est-à-dire insensible aux changements intervenant dans le monde réel. Je reprends un exemple que je cite à l'occasion sur ce forum : si vous identifiez les entreprises par leur n° de Siren, attention ! L’INSEE commet des erreurs en identifiant les nouvelles entreprises et envoie donc des correctifs aux établissements bancaires et autres. Si l’on veut que l’impact soit minimal, le n° de Siren ne doit donc être qu’une clé de rechange (alternate key), un point d'entrée dans une seule table, mais il ne doit certainement pas jouer le rôle de clé primaire...