Pour suivre ce tutorial, il faut connaître :
- La syntaxe SQL SELECT, INSERT, UPDATE
- La notion de contrainte d’intégrité SQL
- Les procédures PHP de connexion aux différentes bases de données
Parallèlement à ce tutorial, vous pouvez consulter le tutorial Récupérer le dernier identifiant généré
Pourquoi ne pas modifier un identifiant existant
Si le besoin de modifier un identifiant dans une de vos bases de données apparaît,
c’est que votre utilisation des identifiant n’est pas correcte.
Un identifiant a pour but d’identifier de manière unique un enregistrement pour le SGBD.
De manière général, les utilisateurs des applicatifs connectés sur cette base de données
ne devraient même pas connaitre les identifiants des données qu’ils manipulent.
De même, un "trou" dans les identifiants d'une table suite à la suppression d'une ligne
ne doit pas être gênante car l'utilisateur ne doit pas s'en apercevoir.
Il est donc très dangereux de modifier les identifiants afin de combler ces "trous".
Les conséquences d’une modification d’un identifiant peuvent mettre en péril
l’intégrité d’une base de données, c'est-à-dire la cohérence des données entre elles.
Imaginons une table « forum » et une table « utilisateur » de la forme suivante :
Code : Tout sélectionner
CREATE TABLE forum (
id_forum int(10) unsigned NOT NULL,
nom varchar(255) NOT NULL,
url varchar(255) NOT NULL,
PRIMARY KEY (id_forum)
)Code : Tout sélectionner
CREATE TABLE utilisateur (
id_utilisateur int(10) unsigned NOT NULL auto_increment,
id_forum int(10) unsigned NOT NULL,
nom varchar(255) default NULL,
prenom varchar(255) default NULL,
login varchar(255) default NULL,
passwd varchar(255) default NULL,
email varchar(255) default NULL,
PRIMARY KEY (id_utilisateur),
KEY id_forum (id_forum)
)La modification de l’identifiant d’un forum peut, s’il n’est pas reporté dans la table « utilisateur »,
créer des utilisateurs qui ne sont reliés à aucun forum. L’intégrité de la table n'est donc plus assurée.
L'exemple le plus fréquent de modification d'identifiant intervient
lorsque qu'un enregistrement est modifié et qu'un développeur veut combler le "trou" laisser dans les identifiants.
Pour faire le lien avec un exemple concret :
À chaque citoyen français est attribué un numéro de sécurité sociale.
Ce numéro est unique et il permet de trouver une personne précise
parmi la masse de personnes disposant d'un numéro de sécurité sociale :
nous pouvons donc dire que ce numéro est l'identifiant des personnes enregistrées.
Quand une personne décède, personne ne change de numéro,
il y a juste un numéro qui devient inutilisé.
Il ne sera jamais réutilisé et aucun décalage n'est réalisé
afin d'éviter qu'un même numéro puisse être affecté à plusieurs personnes
et que chacun perde ses remboursements ou qu'un assuré soit opéré à la place d'un autre.