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.
supergyver
Messages postés29Date d'inscriptionjeudi 19 février 2004StatutMembreDernière intervention14 février 2007 26 oct. 2004 à 01:21
Mysql gère le problème de concurrence avec l'autoincrémente mais pas avec la méthode "manuelle...
------------------------
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é ^^
------------------------
cs_Kirua
Messages postés3006Date d'inscriptiondimanche 14 avril 2002StatutMembreDernière intervention31 décembre 2008 25 oct. 2004 à 17:02
mais à moins que tu ne permettes aux utilisateurs de modifier les structures des bases, je vois pas qd tu pourrais avoir besoin de plus que de la sécurité au niveau des tables, ce qui est tt de même bcp plus fréquemment indispensable.
kofu
Messages postés25Date d'inscriptionvendredi 2 janvier 2004StatutMembreDernière intervention15 mars 2005 25 oct. 2004 à 10:24
C'est vrai que ce code n'est pas recommandé pour être utilisé en concurrence.
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
cs_Kirua
Messages postés3006Date d'inscriptiondimanche 14 avril 2002StatutMembreDernière intervention31 décembre 2008 25 oct. 2004 à 07:52
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é ^^
supergyver
Messages postés29Date d'inscriptionjeudi 19 février 2004StatutMembreDernière intervention14 février 2007 25 oct. 2004 à 01:04
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
cs_Anthomicro
Messages postés9433Date d'inscriptionmardi 9 octobre 2001StatutMembreDernière intervention13 avril 20078 22 oct. 2004 à 22:57
Salut :-)
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 ++
kofu
Messages postés25Date d'inscriptionvendredi 2 janvier 2004StatutMembreDernière intervention15 mars 2005 21 oct. 2004 à 12:35
je rajouterai, pour compléter les dires de Magidev, que dans le cas d'une base de données relationelle (SGBDR), il est utile d'utiliser la mise à jour en cascade. Si un champ d'une table Y pointe sur la clé primaire d'une table X (notions de clés étrangères), et si on change la clé primaire d'un tuple de X, alors le champ de la table Y sera modifié aussi.
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.
kofu
Messages postés25Date d'inscriptionvendredi 2 janvier 2004StatutMembreDernière intervention15 mars 2005 21 oct. 2004 à 12:13
Bonjour,
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
ehmarc
Messages postés393Date d'inscriptionmardi 2 décembre 2003StatutMembreDernière intervention29 septembre 2008 21 oct. 2004 à 09:58
Salut
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....
cs_Kirua
Messages postés3006Date d'inscriptiondimanche 14 avril 2002StatutMembreDernière intervention31 décembre 2008 20 oct. 2004 à 20:59
Note bien que je ne discute pas le fait que ça ait été posté. Même en programmation, la "recherche" pure et gratuite a son intérêt, fut-il seulement pédagogique. Je donne simplement un argument qui va dans le sens de la remarque de Magidev: ok, le code est intéressant, mais ne l'utilisez pas à moins que ça ne se justifie (auquel cas poster ici svp ^^ je serais étonné de trouver une situation où ça s'applique pertinament).
D'ailleurs, je n'ai pas noté le code.
cs_pepito
Messages postés2Date d'inscriptionlundi 27 décembre 1999StatutMembreDernière intervention20 octobre 2004 20 oct. 2004 à 19:57
Il n'en demeure pas moins que, dans certains cas précis, il peut être intéressant d'employer cette fonction (une certaine idée de l'esthétique des séquences) et qu'elle valait la peine d'etre postée.
cs_Kirua
Messages postés3006Date d'inscriptiondimanche 14 avril 2002StatutMembreDernière intervention31 décembre 2008 20 oct. 2004 à 16:29
bien vu Magidev, je te suis totalement sur ce point.
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)
Je ne vois pas vraiment l'utilité vu que le but de l'auto incrément permet d'avoir un numéro unique pour chaque enregistrement. Et rien ne "Sature" il suffit de choisir le format adapté a ton champ, comme INT, BIGINT etc.
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)
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