Je corrige, car me suis apercu que je suis pas clair... mais pas du tout.
tu as par exemple une table mot de passe...
nom varchar (20)
prenom varchar (20)
email varchar (40)
pseudo varchar (10)
passe varchar (32)
id primary key int (10) not null auto_increment
ensuite une table liée, par exemple le profil de la personne soit
pseudo varchar (10)
texte varchar (1024)
photo varchar (256)
etc....
donc un client s'inscrit pour se connecter au site, il crée donc une ligne de la tableMotDePasse
il entre son profil, qui est liée via le pseudo à la connexion.
on a le formulaire de connexion qui renvoie dans une session avec le pseudo comme lien on veut afficher disons la photo d'une personne, on fait donc
select photo from tableprofil where pseudo = '".$pseudo."'" jusque là pas difficile...
mais la personne change son pseudo dans la table de connexion... donc la ligne de profil ne correspond plus à rien puisque le pseudo a été changé..
au départ on avait disons "jean.dubois" dans les deux tables et ensuite "marc.alter" dans la table de connexion et "jean.dubois" dans la table profils... donc marc.alter qui etait jean.dubois n'a plus de profil, plus de posts dans le site, plus rien...
alors on a une solution lorsque le pseudo est modifie dans la table , de faire les updates dans toutes les tables qui contiennent un pseudo, à savoir presque toutes. aie
genre :
update table tableProfils set pseudo = "marc.alter" where pseudo = "jean.dubois"
update table tableBannis set pseudo = "marc.alter" where pseudo = "jean.dubois"
vrai que ici on pourrait faire un lien avec le numero id qui a moins de risque de changer.
le gros risque c'est une erreur dans les commandes, la base de données saturée, la table mot de passe qui est modifiée et pas l'autre table. etc... ou alors une personne envoie à jean.dubois qui se trouve etre en cours de modification sur toutes les tables. alors la procédure sur toutes les tables mets un temps certains. et le programmeur peut oublier des tables aussi. par exemple ne pas voir qu'il lui faut modifier l'information mp_pseudo qui indique le pseudo à qui on a envoyé un message. on peut envoyer à jean.dubois et qu'apres la saisie du message ca soit marc.alter à qui on doit envoyer.
alors on a des transactions pour revenir à zero en cas de gros soucis sur des opérations multiples sur les tables. mais toutes les tables sont concernées et le client doit alors se re connecter avec son ancien nom. et les transactions c'est assez lourd et sont soumises aussi à des oublis... si on mets pas la table des bannis dans la liste des tables et bien un jour "erreur intégrité" infligé aux visiteurs du site...
ensuite alors, les moteurs de bases de données savent faire les choses correctement et sont bien concus. alors que l'on en profite.
alors on crée des contraintes. alors ca peut aller de dire des trucs genre "pseudo ne commence pas par un chiffre" c'est pratique et ca fait des codes faciles à réparer et à lire. mais bon on peut faire à mon sens le controle via le javascript ou via des ereg dans le php...
ou dans le moteur de bases de données, innodb pour mysql... les bases oracle font ca sans penser à installer des trucs.
alors on commence à déclarer une contrainte dans la TableMotDePasse
constraint primary key ("pseudo") ca veut dire que si on modifie pseudo dans la tableMotDePasse les autres tables vont etre modifiées en conséquence.
maintenant tu vas dans ta table profils et tu fais (mais la syntaxe arrive à changer en fonction des moteurs)
constraint foreign key (pseudo) reference tableMotDePasse(pseudo) on update cascade on delete cascade
ca, ca veut dire que l'on mets un contrainte sur l'information pseudo de la table des profils et des bannis
donc la valeur à mettre à jour est pseudo et il faut modifier lorsque l'information pseudo dans la tableMotDePasse est modifiée = reférence tableMotDePasse (pseudo) ensuite on mets ce que l'on fait lors de la mise à jour, ou de la suppression. par exemple le client vire son compte, il ne veut plus de profil
alors comment cela se passe pour le cas de l'envoi d'un message vers un pseudo qui se trouve modifié pendant la saisie... le client envoie son message à jean.dubois mais celui ci devient marc.alter, il fait son insert into messagesPrives values (mp_pseudo, .....) values ("jean.dubois", ...)
alors si tu fais foreign key (mp_pseudo) reference tableMotDePasse (pseudo) là ca va pas forcement marcher... du fait que la cascade sera terminée. donc les clefs etrangeres ne sont pas parfaites mais l'avantage est que l'on n'est plus obligé de tout prévoir au départ. dans ce cas là pendant la saisie on peut faire une lecture ajax du pseudo en continu.
il existe aussi des bases de données (mais là j'ai pas utilisé) ou l'on declare des processus lorsque on lit une table (ici tableMotDePasse) et ensuite le processus fait un insert into de mp_pseudo et là la cascade se redeclenche automatiquement.
j'ai lu aussi que l'on peut mettre des contrainte sur des informations genre "on doublon (pseudo) update" puissant. mais je sais pas si mysql permet de faire ca.... et le update fait ensuite cascade sur les foreign key
bon j'espere etre plus clair que la derniere fois... où vraiment je me suis pas relu moi meme.