Salut,

j'aimerais bien avoir vos avis sur l'UPDATE de clé primaire 8)

Merci d'avance

Ce sujet a déjà été abordé maintes et maintes fois mais je vais te redonner mon avis

Une clé primaire sert uniquement à identifier une ligne parmis d'autre. Tu ne doit pas te soucier de sa valeur. Tu n'as donc pas à la modifier ou la controler. Elle doit être entièrement transparente.

Un de mes profs m'avait même conseillé de ne jamais l'afficher.

Après, explique-nous pourquoi est-ce que tu veux faire ça et on pourra peut être te donner des explications plus précise

Pour identifier un enregistrement, j'utilise une clé primaire composée de 18 chiffres.
Lorsqu'une personne veut supprimer un enregistrement (via interface d'admin), je ne fais pas un DELETE, mais simplement un update de la clé primaire (en modifiant 5 des 18 chiffres de façon à ce que cet enregistrement n'apparaisse plus dans les recherches) ainsi que de 2 autres champs de l'enregistrements.
Ainsi, cette suppression est totalement transparente pour l'ensemble des utilisateurs, mais il reste une trace en base, susceptible d'être exploitée ultérieurement

Update sur une clef primaire ?
T'es pas un peu malade mon gars ? bah, peut-être que tu debutes en dev, mais d'après ce que j'ai appri et d'après les dev que j'ai pu faire, la cle primaire doit-être transparente (utiliser uniquement pour identifier une ligne).
Enfin, c'est un long debat.
Par contre j'ai une question, comment geres-tu tes liaisons entres tes tables si tu t'amuses a manipuler la cle primaire ?

bon courage

bye

Dans ce cas, je ne saurais que te conseiller que de créer un champ "actif" à 1 que tu passes à 0 lors de la désactivation.

Et comme le dit zozoclown, si tu as des clés étrangères sur cette clé primaire, tu conserves le lien et donc l'ensemble des informations dans la base.

Sinon, je suis curieux de voir une application où les clés primaires ont 18 chiffres

@Zozo :

Je réalise un UPDATE sur toutes les tables ou est contenue la clé primaire, ainsi que sur les clés primaires de certaines autres tables (car d'autres tables ont pour clé primaire une partie de la clé primaire de ma première table). Pfiouuu

Et non je débute pas ^^

@ Zeus :

Car cette clé sur 18 chiffres elle a une signification bien précise : chaque chiffre ou groupe de chiffres contenu dans cette clé à un rôle, et signifie quelque chose, dont je me sert dans l'appli.

mouais

Je reste persuadé que tu as une mauvaise utilisation de ta clé primaire mais maintenant, je pense que ta base de données n'est pas correctement modélisée puisque un champ contient plusieurs bout de valeurs.

Comme il est possible définir une clé primaire sur plusieurs champs, j'aurais opté pour un champ par valeur et une clé primaire sur tout ces champs.

Sinon, pour désactiver, je pense que ma solution du champ "actifé à 1 ou 0 permet d'éviter à modifier en série les clé primaire (qui ne devrait jamais être modifiée, je le répete)

Oui, en ce qui concerne le champ 0/1 pour activé/désactivé, je vais le faire (car effectivement c'est une bonne idée).
En ce qui concerne la clé primaire, je vais rapidement réflechir aux modifs à apporter afin d'avoir une clé primaire en auto increment à la place

Merci pour tes conseils

@Zozo :

Je réalise un UPDATE sur toutes les tables ou est contenue la clé primaire, ainsi que sur les clés primaires de certaines autres tables (car d'autres tables ont pour clé primaire une partie de la clé primaire de ma première table pfiou)

Et non je débute pas ^^

.....

Notre ami ne débute pas, et ne se trompe pas non plus.
Il a tout à fait le droit de penser qu'une clé primaire peut être mise à jour.
La seule raison conceptuelle et logique qui empêche la modification d'une clé primaire est la contrainte d'unicité locale et d'intégrité référencielle avec d'autres clés étrangères
Cette raison est levée si la modification de la clé primaire respecte la règle d'unicité et si la modification en cascade est déclenchée sur les liens avec les clés étrangères.

Et comme le dit notre ami, il prouve qu'il a conscience des concéquences de la modification de la clé primaire.

Ceci dit, je ne suis pas tout à fait d'accord avec le fait de voir dans la clé primaire un champ spécialement différent des autres champs d'une table ni toujours un champ numérique "transparent" à l'usage et à cacher.

La clé primaire est un champ comme les autres dont le rôle est spécial : c'est le champ élu pour représenter les enregistrements de la table dans des liens externes (clé étrangère) par exemple un email pour identifier un membre ou un client qui achète en ligne

La clé primaire n'est pas toujours un n° incrémenté, c'est tout simplement une habitude, qui d'ailleurs n'est pas pratique dans le milieu professionnel car le principe renvoi au notion d'accès direct utilisant un n° de rang qui va à l'encontre du principe de l'accès séquentiel-indexé qui lui est basé sur des index choisis parmi les champs de la table.

Le vrai rôle de la clé primaire est de servir comme clé unique d'accès à un enregistrement l'ors d'un passage via une relation de clé étrangère pour réaliser une jointure (passerelle) de données et ainsi étendre l'espace de l'information utile.

Mais le fait qu'un champ soit une clé primaire ne lui attribut guère le rôle exclusif de clé d'accès unique aux enregistrements sinon à quoi servent les index uniques qu'on peut déclarer sur tous les champs de la table

Le rôle d'accès est assigné à tout index unique ou avec doublons, la clé primaire réalise ce rôle car elle est par défaut un index unique.

L'index optimise le procéssus de recherche et d'accès aux enregisrements ciblés

La clé primaire n'est pas la seule à identifier d'une façon unique un enregistrement contrairement à ce qu'on peut penser, car elle ne peut empêcher malheureusement l'enregistrement d'au moins 2 lignes de données semblables ayant 2 clé primaires différentes.
Exemple: En enregistrant le même étudiant 2 fois avec 2 clés primaires différentes

Et pour palier à ce problème des indexes uniques doivent être mis en place sur d'autres champs pour garder l'unicité de l'enregistrement.

En conclusion, je peux dire que la clé primaire (base du modèle relationnel) sert à nouer des relations avec les autres tables en représentant un enregistrement au plus de sa table.
En modifiant ou supprimant cette clé primaire on touche à l'intégrité de l'enregistrement et de ses relations.
Il faut donc prendre les précautions nécéssaires si on permet la modification et/ou la suppression de la clé primaire en activant les triggers de modification et/ou suppression en cascade.

Et noter bien, que le principe de clé primaire n'existe pas dans les modèles de données objets car pour ces derniers, une classe (objet table) est encapsulée (référencée) en entier l'ors d'une relation étrangère dans une autre classe.

ps: Je te conseille donc d'activer les triggers de cascade sur tes relations PK/FK pour autoriser l'Update et le Delete de PK sans efforts supplémentaires (si tu est sur une BD mysql de type innodb ou sur mssql, oracle, access et équivalent)

Merci pour ta réponse
Pour info, je suis sur MySQL 3.23 avec des tables de type MyISAM, donc pas de triggers.