SE PASSER DE L'AUTO INCRÉMENT
Utilisateur anonyme
-
20 oct. 2004 à 01:40
kofu Messages postés 25 Date d'inscription vendredi 2 janvier 2004 Statut Membre Dernière intervention 15 mars 2005 - 26 oct. 2004 à 19:08
kofu Messages postés 25 Date d'inscription vendredi 2 janvier 2004 Statut Membre Dernière intervention 15 mars 2005 - 26 oct. 2004 à 19:08
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/26961-se-passer-de-l-auto-increment
https://codes-sources.commentcamarche.net/source/26961-se-passer-de-l-auto-increment
26 oct. 2004 à 19:08
pour plus d'infos quant à l'utilisation des auto incréments, je vous conseille de vous référer à cet article:
http://sqlpro.developpez.com/cours/clefs/
A priori, l'utilisation d'une "table de clés" serait la solution la plus sûre, et la plus portable.
C'est d'ailleurs celle ci que j'utilise actuellement, getCode étant mon ancien système, je n'utilisais pas la concurrence.
N'hésitez pas à donner votre avis.
26 oct. 2004 à 01:21
------------------------
Si deux internautes utilisent cette fonction pour ajouter un nouvel enregistrement il peut y avoir concurrence.
En effet, 'A' utilise la fonction qui lui renvoie 3.
'B' utilise la même fonction qui lui renvoie 3 aussi...
'A' fait son insertion, là c'est OK.
'B' fait son insertion et là... boom!!! insertion impossible
------------------------
tu veux dire s'ils le font en même temps? c'est le cas aussi en temps normal, avec auto increment, mais que je sache il n'y a jms de problème. mysql gère ce genre de situations. je ne sais pas comment, mais c'est géré ^^
------------------------
25 oct. 2004 à 17:02
25 oct. 2004 à 10:24
Il faut utiliser les transactions, en la dbutant avant getCode et en la terminant par un commit après l'insertion.
Au sujet de mysql et de sa gestion des concurrence, elle "ferait" du transactionnel au niveau TABLE, mais pas au niveau BdD ... Bref, elle gère la concurrence sur deux accès simultanés à la même table mais pas deux accès simultanés sur la même base de données
Corrigez moi si je me trompe
25 oct. 2004 à 07:52
25 oct. 2004 à 01:04
En effet, 'A' utilise la fonction qui lui renvoie 3.
'B' utilise la même fonction qui lui renvoie 3 aussi...
'A' fait son insertion, là c'est OK.
'B' fait son insertion et là... boom!!! insertion impossible
22 oct. 2004 à 22:57
Le problème de ce code est qu'il est très gourmand pour une table comportant des milliers d'enregistrements...
mais l'idée est intéressante.
a ++
21 oct. 2004 à 12:35
Ainsi, pas de perte de données.
En ce qui concerne la destruction d'un utilisateur de forum, on peut attribuer ses messages à l'utilisateur fictif "un membre déserteur" par exemple.
Bref, tout ça pour dire et répèter que cette fonction n'est pas forcement LA solution à utiliser, mais qu'elle peut être pratique et dépanner certaines personnes.
21 oct. 2004 à 12:13
Il est clair que ce code est inutile pour les applications les plus courantes, mais je me suis dis que dans certains cas bien précis, elle pourrait l'être.
Toujours dans les recherches sur l'utilisation des clés primaires, j'ai créé un portail qui gère rubriques, articles etc.
L'ordre d'apparition est géré par les clés primaires (en termeinant la requête par un ORDER BY code ASC.
Pour modifier l'ordre d'apparition, il suffit d'échanger deux clés primaires.
Ca évite d'utiliser un champ "ordre", et les clés primaires ne sont pas dénaturées: Elles gardent leur fonction d'identifiant unique
Je ne pense pas que ce concept soit "nul", ou "excellent", mais juste "différent" ;)
Actuellement je suis sur un éditeur HTML WYSIWYG compatible avec mozilla, IE et opera, si quelqu'un est interessé pour me donner un coup de main, n'hésitez pas à me contacter à l'adresse se trouvant dans mon profil
@ bientôt pour d'autres sources bizzaroïdes
21 oct. 2004 à 09:58
Bin moi j'en ai besoin :p enfin un peu modifier (bon l'architecture de ma base est pas tres jolie mais elle m'est imposé donc...)
Dans mon cas, les index me servent juste pour une sélection plus simple apres l'affichage (je renvoie le numéro d'index à la page suivante... avec mon lien) sinon j'ai entendu parler de moulinette qui ferai ce genre de truc proprement (voir le cas du phorum plus haut) mais ceux que j'ai trouver sont payant....
20 oct. 2004 à 20:59
D'ailleurs, je n'ai pas noté le code.
20 oct. 2004 à 19:57
20 oct. 2004 à 16:29
je rajouterai que si l'id a une signification par rapport aux données (par exemple, tu fais un script de votes pour une série de concours que tu organises, tu mets alors comme id le numéro du concours: il y a un sens direct), tu n'auras pas le problème de savoir s'ils se suivent ou pas: ça n'a plus de sens. Si par contre ton id n'est pas en relation directe avec les données: c'est uniquement un nombre qui permet d'identifier (justement) ces données précises, avec peu de mémoire, alors le fait que la série d'ID soit discontinue n'est pas un problème non plus: ce n'est pas une partie significative des données, on n'affiche jamais l'id, sauf dans les liens etc...
Donc on a bien que dans les deux cas qui peuvent se présenter, avoir une discontinuité dans les id ne pose pas de problème (même si on est bien d'accord que c'est moche :p)
20 oct. 2004 à 01:40
De plus, pour les Bases de données Relationnelles cela peut poser probleme, et meme de sérieux
Imagine que on utilise ton principe pour des utilisateurs
dans un forum par exemple.
Après chaque message du forum on attache l'ID de la personne qu'il l'a postée.
ID---MESSAGE---AUTEUR
0 Test 1
1 Bonjour 2
2 Test 3
A partir de la, l'administrateur décide de supprimer le compte de l'utilisateur 3, mais il ne va pas vider tout ses messages du forum car ils sont interessant pour la plus part
Quand on consultera un message, et que l'on voudra récupérer l'auteur, on se retrouve devant un probleme, si personne ne s'est inscrit entre temps, il n'y a pas d'enregistrement 3 , la c'est OK mais si quelqu'un s'inscrit entretemps, on se retrouve avec qqn dont l'ID est 3 et qui n'EST PAS l'auteur des messages.
Donc pour utiliser ta méthode sans avoir de problemes, il faudrait ré-attribuer tout les champs de la table forum a un auteur 0 si il est supprimé, mais voila le probleme, cela demande plus de traitement et de vérifications par code que cela n'économise de place dans la base ou de performance.
En lui même le code est intéréssant pour son fonctionnement. Mais je pense qu'il ne doit pas etre utilisé pour une application concrete de base de données sinon on se retrouve devant plusieurs dilemes surtout en cas de base de données relationnelles (tres courantes)
Bonne prog