Clé etrangere
Fermé
miminaou
Messages postés
4
Date d'inscription
mardi 19 mai 2009
Statut
Membre
Dernière intervention
8 juin 2009
-
19 mai 2009 à 23:29
leon91490 Messages postés 166 Date d'inscription mardi 19 mai 2009 Statut Membre Dernière intervention 9 septembre 2017 - 13 juil. 2009 à 22:55
leon91490 Messages postés 166 Date d'inscription mardi 19 mai 2009 Statut Membre Dernière intervention 9 septembre 2017 - 13 juil. 2009 à 22:55
A voir également:
- Clé etrangere
- Clé windows 10 gratuit - Guide
- Cle usb non reconnu - Guide
- Clé bootable windows 10 - Guide
- Recuperer cle windows - Guide
- Formater clé usb mac - Guide
4 réponses
leon91490
Messages postés
166
Date d'inscription
mardi 19 mai 2009
Statut
Membre
Dernière intervention
9 septembre 2017
47
20 mai 2009 à 01:12
20 mai 2009 à 01:12
pas difficile à faire...
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 le mec s'est inscrit mais il a un profil pour parler de lui
alors soit tu fait le lien avec le id apres un "select * from tableMotDePasse where pseudo = ".$_post["pse"]." and passe = ".$_post ["passe"]
soit tu mets le pseudo dans les autres tables dont le profil...
alors tu modifies le pseudo dans la table principale et tu as aussi le pseudo dans la table de profil.. et donc lorsque quelqu'un qui visite le profil ne peut jamais recevoir de messages car il se connecte sur un autre pseudo et les sessions n'envoie un pseudo qui n'a pas de profil. aie :!!!! content le mec qui a peaufine sa drague fatale pendant deux heures.
alors tu as une soluce de base à faire en discret
"update table TableMotDePasse set pseudo =".$nouveauPseudo." where pseudo =".$_Session["pseudo"];
tu reprends le code d'erreur ou pas... si pas erreur alors
"update table TableProfils set pseudo =".$nouveauPseudo." where pseudo =".$_Session["pseudo"];
le gros probleme c'est quand la seconde routine qui modifie le pseudo plante alors que la premiere a modifié. alors souvent on rentre dans des trucs genre souvent tres spéciaux. à savoir faire des transactions et supprimer la transaction lorsque une erreur arrive sur toute la liste et alors le client est de toute facon pas content. il a changé son pseudo et CA NE MARCHE PAS.
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")
alors ca veut dire que la clef primaire est modifié et les foreign key sont modifiées en conséquence. si probleme rien ne se fait...
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
donc ici on demande : modifier la valeur pseudo si la valeur pseudo de la table mot de passe change.
Ou effacer l'enregistrement contenant pseudo si on efface celui de tableMotDePasse contenant pseudo.
y a postgresSQL qui fait directement la foreign key et le necessaire dans la table de depart....
constraint foreign key (pseudo, email) référence tableMotDePasse (pseudo, email)
bon j'espere m'etre fait comprendre. ou alors envoie moi un message privé... je referais le bilan sur le forum. mieux je trouve que d'aligner une série de dialogues genre "mais il me mets error 500" qui n'apportent rien.
mais c'est le principe général que je donne.
1- dans chaque table, se dire "est ce que cela peut etre modifié ?" alors on mets en primary key
2- dans les tables jointes, on mets les valeurs à modifier et quoi faire en cas de modif ou de suppression.
et tu as meme des moteurs qui friment bien... genre tu change un numero de sécu à paris... tu as un serveur de base de données à lyon... avec foreign key à lyon reférence à paris. donc on modifie celui à paris et celui de lyon est modifié aussi.
j'ai fait ca dans les années 80 sur une base oracle... et je donne le principe de base des constraints avec clefs primaires. ca change en fonction des bases de données et aussi des fois des moteurs (engines) utilisés.
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 le mec s'est inscrit mais il a un profil pour parler de lui
alors soit tu fait le lien avec le id apres un "select * from tableMotDePasse where pseudo = ".$_post["pse"]." and passe = ".$_post ["passe"]
soit tu mets le pseudo dans les autres tables dont le profil...
alors tu modifies le pseudo dans la table principale et tu as aussi le pseudo dans la table de profil.. et donc lorsque quelqu'un qui visite le profil ne peut jamais recevoir de messages car il se connecte sur un autre pseudo et les sessions n'envoie un pseudo qui n'a pas de profil. aie :!!!! content le mec qui a peaufine sa drague fatale pendant deux heures.
alors tu as une soluce de base à faire en discret
"update table TableMotDePasse set pseudo =".$nouveauPseudo." where pseudo =".$_Session["pseudo"];
tu reprends le code d'erreur ou pas... si pas erreur alors
"update table TableProfils set pseudo =".$nouveauPseudo." where pseudo =".$_Session["pseudo"];
le gros probleme c'est quand la seconde routine qui modifie le pseudo plante alors que la premiere a modifié. alors souvent on rentre dans des trucs genre souvent tres spéciaux. à savoir faire des transactions et supprimer la transaction lorsque une erreur arrive sur toute la liste et alors le client est de toute facon pas content. il a changé son pseudo et CA NE MARCHE PAS.
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")
alors ca veut dire que la clef primaire est modifié et les foreign key sont modifiées en conséquence. si probleme rien ne se fait...
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
donc ici on demande : modifier la valeur pseudo si la valeur pseudo de la table mot de passe change.
Ou effacer l'enregistrement contenant pseudo si on efface celui de tableMotDePasse contenant pseudo.
y a postgresSQL qui fait directement la foreign key et le necessaire dans la table de depart....
constraint foreign key (pseudo, email) référence tableMotDePasse (pseudo, email)
bon j'espere m'etre fait comprendre. ou alors envoie moi un message privé... je referais le bilan sur le forum. mieux je trouve que d'aligner une série de dialogues genre "mais il me mets error 500" qui n'apportent rien.
mais c'est le principe général que je donne.
1- dans chaque table, se dire "est ce que cela peut etre modifié ?" alors on mets en primary key
2- dans les tables jointes, on mets les valeurs à modifier et quoi faire en cas de modif ou de suppression.
et tu as meme des moteurs qui friment bien... genre tu change un numero de sécu à paris... tu as un serveur de base de données à lyon... avec foreign key à lyon reférence à paris. donc on modifie celui à paris et celui de lyon est modifié aussi.
j'ai fait ca dans les années 80 sur une base oracle... et je donne le principe de base des constraints avec clefs primaires. ca change en fonction des bases de données et aussi des fois des moteurs (engines) utilisés.
rachidou12
Messages postés
87
Date d'inscription
dimanche 11 janvier 2009
Statut
Membre
Dernière intervention
10 juin 2010
3
20 mai 2009 à 00:26
20 mai 2009 à 00:26
salamo alaykoum
En sql server , c'set au moment de la declaration que tu doit le preciser ,et preciser aussi la table qui contient ce champs comme clé primaire et ca ne doit pas etre different avec mySQL
voila mais je ne suis pas sur de la syntaxe tu cherche mais la logique est bonne :
etudiant filiere
num primary key num_fil primary key
nom intitule
num_fil foreigne key (filiere)
En sql server , c'set au moment de la declaration que tu doit le preciser ,et preciser aussi la table qui contient ce champs comme clé primaire et ca ne doit pas etre different avec mySQL
voila mais je ne suis pas sur de la syntaxe tu cherche mais la logique est bonne :
etudiant filiere
num primary key num_fil primary key
nom intitule
num_fil foreigne key (filiere)
sandul
Messages postés
3924
Date d'inscription
jeudi 22 mai 2008
Statut
Membre
Dernière intervention
8 octobre 2010
722
20 mai 2009 à 00:29
20 mai 2009 à 00:29
Salut,
https://fr.wikipedia.org/wiki/Cl%C3%A9_%C3%A9trang%C3%A8re
Ou bien, en plus complet, par là: https://en.wikipedia.org/wiki/Foreign_key
Hey, je t'invite cordialement à contempler avec attention la signature d'un gars appelé Marco la Baraque... rtfm... :-)
++
https://fr.wikipedia.org/wiki/Cl%C3%A9_%C3%A9trang%C3%A8re
Ou bien, en plus complet, par là: https://en.wikipedia.org/wiki/Foreign_key
Hey, je t'invite cordialement à contempler avec attention la signature d'un gars appelé Marco la Baraque... rtfm... :-)
++
rachidou12
Messages postés
87
Date d'inscription
dimanche 11 janvier 2009
Statut
Membre
Dernière intervention
10 juin 2010
3
20 mai 2009 à 00:35
20 mai 2009 à 00:35
tout dabrd dsl pour le desordre ca devai etre comme ca :
1)_etudiant
-num primary key
-nom
-num_fil foreigne key (filiere)
2)_filiere
-num_fil primary key
-intitule
et je vais voir la signature ca doit etre semblable a la mien ou c l'inverse pe etre =)
1)_etudiant
-num primary key
-nom
-num_fil foreigne key (filiere)
2)_filiere
-num_fil primary key
-intitule
et je vais voir la signature ca doit etre semblable a la mien ou c l'inverse pe etre =)
13 juil. 2009 à 22:55
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.