Récupération d'une clé qui vient d'être insérée

Récupération d'une clé qui vient d'être insérée - SQL/NoSQL - Programmation

Marsh Posté le 10-02-2005 à 20:50:23    

Bonjour à tous,
 
voici mon problème, dans une table mysql, la clé est un champs qui s'autoincrémente.
 
je fais ceci
 
insert into table
values (
'', 'moi') où le '' est la clé, pas la peine de rentrer une valeur puisque ce champs s'auto incrémente.
 
mon but après avoir fait cette insertion, est d'en récupérer la clé ha ha.
 
comment le faire puisqu'une selection UNIQUE ne se fait qu'à l'aide une clé :(
 
vous avez compris?

Reply

Marsh Posté le 10-02-2005 à 20:50:23   

Reply

Marsh Posté le 10-02-2005 à 23:00:59    

Google powaaaaa !
 
Recherche sur : mysql retrieve key autoincrement
 
2nd résultat : http://sunsite.mff.cuni.cz/MIRRORS [...] EMENT.html
 
=> "You can retrieve the used AUTO_INCREMENT key with the LAST_INSERT_ID() SQL function or the mysql_insert_id() API function."

Reply

Marsh Posté le 10-02-2005 à 23:32:44    

je te remercie pour la peine que tu t'es donnée, mais étant donné qu'il y aura des dizaines voir des centaines d'insertion par seconde je doute fort que cette méthode soit efficace.
 
sinon j'ai résolu le problème autrement. en fait j'explique ce que je voulais faire
 
je voulais créer un enregistrement d'une table "machin". à cet enregistrement je voulais associer 3 images dans une table "image" qui contient entre autre l'id de la table "machin". pour cela il me fallait l'id de la table "machin"
 
j'ai donc ajouté des champs qui correspondes aux 3 images dans la table "machin". c'est moins élégant mais efficace :)
 
en tout cas merci beegee ;)

Reply

Marsh Posté le 10-02-2005 à 23:38:47    

Je vois 2 methodes :  
 
1ere comme l'a dit beegee ... pour controler que c'est bien la bonne je crois que mysql possede une commande qui permet de mettre les requetes en file d'attente quand elles arrivent ... il suffirait donc de lancer les 2 requetes (insert + lastid) dans un meme paquet (pourquoi pas avec une requete preparée) ...
 
Sinon on peut le faire avec un ID unique ... genre ton insert tu lui met avec un temps en nanosec et c'est reglé


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 11-02-2005 à 06:56:59    

senomo a écrit :

je te remercie pour la peine que tu t'es donnée, mais étant donné qu'il y aura des dizaines voir des centaines d'insertion par seconde je doute fort que cette méthode soit efficace.


 
Je vois pas trop en quoi le fait d'insérer des centaines de lignes par seconde va poser un problème, tu devrais pouvoir faire des milliers d'insertion par seconde si tu fais juste des INSERT suivis de récupération de la clé (pour d'autres INSERT).
 
Et s'il te faut plus de perfs, regarde le lien que je t'ai passé, tu peux insérer en block, et récupérer le premier ID utilisé grâce à mysql _insert_id() (les autres en découlent logiquement ...).

Reply

Marsh Posté le 11-02-2005 à 11:11:29    

en gros si j'ai bien compris, l'insert et le last_id doivent être dans une même requête. intéréssant en effet, je n'y avais pas pensé.
 
merci beaucoup les gars :jap:

Reply

Marsh Posté le 11-02-2005 à 11:58:47    

On dirait qu'on ne peut pas travailler avec de connection partagée si on utilise the LAST_INSERT_ID().
 
C'est un peu gênant, non ?


---------------
Now Playing: {SYNTAX ERROR AT LINE 1210}
Reply

Marsh Posté le 11-02-2005 à 13:14:35    

un
 
SELECT MAX(id) FROM nomtable;  
 
devrait faire l'affaire dans ton cas non en mysql!
 
perso c'est pas méga le bon plan étant donné que mysql c'est de la boos qui respecte rien...
 
sous oracle la technique pourrait etre la même, mais pour être sure que ce soit bien le dernier id encodé, on creerais une transaction juste avant afin que la donnée soit cohérente....


Message édité par moi23372 le 11-02-2005 à 13:16:53
Reply

Marsh Posté le 11-02-2005 à 13:34:31    

moi23372 a écrit :

un
 
SELECT MAX(id) FROM nomtable;  
 
devrait faire l'affaire dans ton cas non en mysql!


Certainement pas !!! :o


---------------
Now Playing: {SYNTAX ERROR AT LINE 1210}
Reply

Marsh Posté le 11-02-2005 à 13:59:41    

si tu le dis

Reply

Marsh Posté le 11-02-2005 à 13:59:41   

Reply

Marsh Posté le 11-02-2005 à 14:06:20    

moi23372 a écrit :


perso c'est pas méga le bon plan étant donné que mysql c'est de la boos qui respecte rien...


Pourquoi dis-tu que mysql ne respecte rien :??:

Reply

Marsh Posté le 11-02-2005 à 14:19:51    


Tu peux prendre ça pour argent comptant.
 
Le INSERT suivi du SELECT MAX ne constituent pas une opération atomique. Entre ces deux opérations, un autre utilisateur/process peut avoir fait un INSERT, et le résultat de ton SELECT sera incorrect.


---------------
Now Playing: {SYNTAX ERROR AT LINE 1210}
Reply

Marsh Posté le 11-02-2005 à 15:23:53    

merci les gars pour toutes vos réponses, ce que j'ai fait, pour ne pas avoir à récupérer l'id, c'est d'insérer directement les 3 images dans la table sans créer une table propre aux images. je sais je me suis dégonflé trop tôt :(
mais ça marche :)
 
sinon vos remarques sont extrèmement constructives :jap:

Reply

Marsh Posté le 11-02-2005 à 16:16:54    

sircam a écrit :

Tu peux prendre ça pour argent comptant.
 
Le INSERT suivi du SELECT MAX ne constituent pas une opération atomique. Entre ces deux opérations, un autre utilisateur/process peut avoir fait un INSERT, et le résultat de ton SELECT sera incorrect.


 
 
OUi est c'est pour ca qu'on fait un LOCK avant le insert puis un UNLOCK apres le last_insert_id pour êter sûr de son coup!!!

Reply

Marsh Posté le 11-02-2005 à 16:35:37    

rompi a écrit :

OUi est c'est pour ca qu'on fait un LOCK avant le insert puis un UNLOCK apres le last_insert_id pour êter sûr de son coup!!!


[:kiki] Super pour les perfs...


---------------
Now Playing: {SYNTAX ERROR AT LINE 1210}
Reply

Marsh Posté le 15-02-2005 à 13:35:47    

C'est quoi ta solution "opération atomique" sircam ?
 
je n'ai jamais une de problème des problèmes de perf concernant, LOCK INSERT SELECT Last_insert_id() UNLOCK

Reply

Marsh Posté le 15-02-2005 à 13:59:59    

Tu as donné la solution atomique toi-même. Simplement, ce qui précédait ne l'était pas (personne n'a parlé de LOCK).
 
Maintenant, revers de la médaille, obtenir un lock sur toute une table dégrade les performances. Tu n'as jamais eu de pb parce que dans la pratique, c'est uniquement dans le cas d'une charge maximale que cela se manifestera, sous forme d'un bottleneck pas toujours évident à détecter.
 
Ceci dit, je m'interroge sur la portée exacte du lock :

Citation :

LOCK TABLES locks tables for the current thread


Cela veut-il dire qu'un autre thread pourra malgré tout accéder à la table, malgré le lock ? Mes connaissances en MySQL s'arrêtent là mais ça vaut la peine de se poser la question.


---------------
Now Playing: {SYNTAX ERROR AT LINE 1210}
Reply

Marsh Posté le 15-02-2005 à 14:04:07    

je dis peut-être une bétise mais j'avais vu une solution avec une ID temporaire...
 
Du genre : INSERT mes donnes +  monIDTemporaireQuiEstUnique
 
et récupération de l'ID auto-incrémentée par un SELECT monIDTemporaireQuiEstUnique...
 
Mais niveau perf, je sais pas ce que ça vaut...


---------------
« Lorsque le bûcheron pénétra dans la forêt avec sa hache, les arbres se dirent : ne nous inquiétons pas, le manche est des nôtres. » | Gérez votre collection de BD en ligne !
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed