xeroxiss
Messages postés85Date d'inscriptionsamedi 30 juillet 2005StatutMembreDernière intervention 7 mai 2009
-
23 déc. 2007 à 11:49
cs_fanti -
1 avril 2008 à 00:52
Bonjour tout le monde
Voilà je me demandais juste un petit truc, et peut être que vous connaissez la réponse...
J'ai deux tables mysql et un formulaire d'inscription pour mes membres.
Je fait deux insert pour des valeurs différentes de mon formulaire.
Par exemple : L'utilisateurs remplis tout les champs, une partie des valeurs s'insert dans une table et une autre partie dans une autre...
Jusque là pas de soucis, maintenant je désirai faire la jonctions (la connexion) entre les deux tables. Pour qu'une fois que le membre
se connect, je puisse, en variable session, récupérer toutes les infos concernant ce membres.
J'ai bien lu plein de post concernant, mysql_inserid() ou @@INDENTIFY, mais je ne sais pas trop bien l'idée au moment de l'insert.
Voilà, je pense que c'est tout bête !!
Merci beaucoup
neigedhiver
Messages postés2480Date d'inscriptionjeudi 30 novembre 2006StatutMembreDernière intervention14 janvier 201119 23 déc. 2007 à 21:27
Hum.
mysql_insert_id() renvoit le dernier ID inséré. C'est une valeur à insérer. Donc, à la place de '$id_user', dans la liste des valeurs. Pas après, ça n'a aucun sens (en plus, c'est une belle erreur de syntaxe).
Il faut D'ABORD exécuter la première requête. Pas simplement l'écrire. L'exécuter, c'est à dire avec mysql_query().
Ce n'est qu'ensuite que mysql_insert_id() te renverra l'id inséré.
mysql_insert_id() n'est pas une requête, mais une fonction PHP, qui utilise l'API C de MySQL pour obtenir des informations du serveur.
Shématiquement :
$add_membre = ......
mysql_query($add_membre);
// A partir de là, mysql_insert_id() peut être exécutée, mais pas avant
$add_annonce = ......
mysql_query($add_annonce);
bizibiz17
Messages postés142Date d'inscriptionmardi 17 janvier 2006StatutMembreDernière intervention29 août 20091 24 déc. 2007 à 00:01
Le champs id_user doit être un numéro auto, il ne faut donc pas le mettre dans ta requete !
Ensuite tu fais deux fois la même requete, je pense que tu n'as pas complètement saisi ce qu'on a voulu te dire même si tu es sur la bonne voix.
Essaye de modifier ça pour que ça soit correct parce que là...c'est franchement bizarre que ça marche, par curiosité tu le prend où ton id_user ?
neigedhiver
Messages postés2480Date d'inscriptionjeudi 30 novembre 2006StatutMembreDernière intervention14 janvier 201119 23 déc. 2007 à 12:06
Salut,
Je ne vois pas l'intérêt d'avoir une table séparée pour stocker la description d'un utilisateur. En fait, tu y perds en performances.
On stocke normalement dans une seule table les informations concernant un utilisateur. Si tu devais avoir plusieurs fois le même champ pour chaque utilisateur, alors seulement une deuxième table serait justifiée. Là, franchement, tu te compliques la vie pour rien.
J'en profite pour te conseiller de mettre un index dans ta table (numérique, plutôt que texte, ce qui exclue l'indexation de la table sur le champ email... pour des raisons de performances.
Si chaque utilisateur n'a qu'une seule description (le contraire n'ayant pas réellement de sens commun, à moins que tu n'aies un besoin très spécifique), alors autant tout laisser dans une seule table : multiplier les requêtes multiplie également le temps d'exécution, la charge du processeur, etc.
Vous n’avez pas trouvé la réponse que vous recherchez ?
malalam
Messages postés10839Date d'inscriptionlundi 24 février 2003StatutMembreDernière intervention 2 mars 201025 23 déc. 2007 à 12:42
Hello,
certes...mais ça se défend dans le cadre de gros, gros applicatifs.
Enfin...je ne vais pas critiquer la façon de faire parce que je le fais actuellement. Je te donne juste une solution :
Tu as doit avoir une table "primaire". Par exemple, at table1.
Puis dans ta/tes table(s) secondaire(j'arrête les S c'est saoûlant, vous aurez compris), tu lies tes entrées à l'ID de ta table primaire :
donc tu fais ton second INSERT avec le @@IDENTITY (désolé, je bosse plus sur mssql en ce moment) de ta première insertion, dans la table users.
Et quand tu récupères le tout :
SELECT user.user_nom, user.user_prenom...usernum.usernum_email...
FROM users user
INNER JOIN users_coord_num usernum ON usernum.user_id = user.user_id
WHERE user.user_id = $iUserId
Et quand tu me dit de mettre un index... J'ai déja un 'userid' autoincrémente sur la table membre, et un 'annid' sur la table annonce.
Mon problème c'est que j'aimerai affiché l'annonce correspondant au membre. Par exemple a sa connexion.
Et au cas ou le membre rajouterai une annonce, il faudrait que sa deuxième annonce soit liée a son compte.
Merci de ton explication, mais si tu peux m'aider dans cette voie la..
malalam
Messages postés10839Date d'inscriptionlundi 24 février 2003StatutMembreDernière intervention 2 mars 201025 23 déc. 2007 à 12:58
Malalam a toujours raison, c'est l'admin du site ;-) (je plaisante hein, j'ai parfois tort...des fois...ça arrive quoi...c'est rare mais bon...et puis j'autorise personne à le dire hein, que ce soit clair!!)
bizibiz17
Messages postés142Date d'inscriptionmardi 17 janvier 2006StatutMembreDernière intervention29 août 20091 23 déc. 2007 à 13:16
Oui Merise peut parraître un peu compliqué, c'est sûr que si tu as deux tables ça te sert pas à grand chose mais dès que tu as une grosse base de données tu es obligé de t'en servir sinon tu t'en sort pas...
malalam
Messages postés10839Date d'inscriptionlundi 24 février 2003StatutMembreDernière intervention 2 mars 201025 23 déc. 2007 à 13:16
bizibiz17 te donne la clef (je renvoie l'ascenceur ;-) ). Merise, malgré son grand âge, reste une référence toujours utile à consulter.
Voilà une url que je consulte régulièrement quand j'ai des doutes :
http://www.sam-mag.com/P53,53,5,43,,,default.aspx Cet article est vieux, mais il reste totalement d'actualité. Il explique Merise en des termes simples, avec des exemples très à propos. C'est le meilleur article que je connaisse sur le sujet.
Il faut que tu comprennes le concept de "clef étrangère". C'est une clef commune à plusieurs tables. Un peu comme ta famille proche : la clef commune entrre toi, ta mère, ton père, ta grand-mère paternelle etc... c'est ton nom de famille (sous réserve de spécificité familiale du genre ma mère a gardé son nom de jeune fille hein!). Tu veux tous les DURAND, qui appartiennent à diverses tables ? Ta clef commune, c'est "DURAND", dans la table "parents", "grand_parents", "enfants", "petits_enfants" etc...
bizibiz17
Messages postés142Date d'inscriptionmardi 17 janvier 2006StatutMembreDernière intervention29 août 20091 23 déc. 2007 à 14:27
Il ne faut pas que tu fasse un insert de tes "id" (id_user dans la table membre et id_ann dans annonces) car ils doivent être auto car uniques.
Pour le id_user dans la table annonces il faut que tu fasse une requete qui récupère l'id de l'utilisateur qui a déposé l'annonce et que tu mette cette valeur dans ta table pour que cela corresponde bien. Après tu pourra donc récupérer toutes les annonces d'un membre.
xeroxiss
Messages postés85Date d'inscriptionsamedi 30 juillet 2005StatutMembreDernière intervention 7 mai 2009 23 déc. 2007 à 18:29
Oui ce lien je l'es lu et relus !!!
Le problème c'est comme je fait deux insert, le premier dans la table membre et le deuxième dans la table annonces...
Mysql va peu etre confondre, en plus de ca... Il me parle de printf ?? alors que je doit juste inserer l'id... et en plus l'id se nomme id_user...je peu donc pas changé la function php...
printf("Le dernier ID inséré dans est le id %d\n", mysql_insert_id());
J'avoue que là...J'était la péniche dans le pacifique, maintenant je suis le Titanic dans l'antartique...