Lorsque tu reçois le message du client, tu en tire un identifiant unique, comme par exemple un md5 ou sha. Cet identifiant dépend du contenu du message ! Donc si un utilisateur reposte le même message, celui-ci aura le même identifiant, et donc il sera impossible de l'enregistrer en bdd.
Donc cette solution est très interessante pour éviter le multipost (volontaire ou pas, peu importe)
Et simplement utiliser l'attribut "unique" du champ, c'est pas plus simple?
L'attribut unique dans ce cas peut poser le problème du choix du champ unique.
si c'est un patronyme, il peut y avoir des homonymes si c'est l'adresse, les immeubles peuvent abriter plusieures personnes sous la même adresse, la date de naissance ne marche pas non plus.
Bref, mis à part de rare cas ou une valeur unique de champ peut fonctionner, ce n'est généralement pas le cas
Cordialement Démosthène
Lorsque tu reçois le message du client, tu en tire un identifiant
unique, comme par exemple un md5 ou sha.
Cet identifiant dépend du contenu du message ! Donc si un utilisateur
reposte le même message, celui-ci aura le même identifiant, et donc il
sera impossible de l'enregistrer en bdd.
Donc cette solution est très interessante pour éviter le multipost
(volontaire ou pas, peu importe)
Et simplement utiliser l'attribut "unique" du champ, c'est pas plus simple?
L'attribut unique dans ce cas peut poser le problème du choix du champ
unique.
si c'est un patronyme, il peut y avoir des homonymes
si c'est l'adresse, les immeubles peuvent abriter plusieures personnes
sous la même adresse, la date de naissance ne marche pas non plus.
Bref, mis à part de rare cas ou une valeur unique de champ peut
fonctionner, ce n'est généralement pas le cas
Lorsque tu reçois le message du client, tu en tire un identifiant unique, comme par exemple un md5 ou sha. Cet identifiant dépend du contenu du message ! Donc si un utilisateur reposte le même message, celui-ci aura le même identifiant, et donc il sera impossible de l'enregistrer en bdd.
Donc cette solution est très interessante pour éviter le multipost (volontaire ou pas, peu importe)
Et simplement utiliser l'attribut "unique" du champ, c'est pas plus simple?
L'attribut unique dans ce cas peut poser le problème du choix du champ unique.
si c'est un patronyme, il peut y avoir des homonymes si c'est l'adresse, les immeubles peuvent abriter plusieures personnes sous la même adresse, la date de naissance ne marche pas non plus.
Bref, mis à part de rare cas ou une valeur unique de champ peut fonctionner, ce n'est généralement pas le cas
Cordialement Démosthène
nico
ASM wrote:
ASM wrote:
La seule solution propre passe par une base de données avec clé unique, calculée sur les données entrées par l'utilisateur (et non pas en auto-incrément).
Oui? tu peux expliquer ?
Lorsque tu reçois le message du client, tu en tire un identifiant unique, comme par exemple un md5 ou sha.
ha! ha! voilà qui est interressant ! et ne m'éclaire pas du tout ! (je suis une crasse en bdd et en bp d'autres choses) on va voir ce que nous en dit google.
Le md5 ou le sha, c'est une technique de hashage. C'est à dire que l'on prend une suite binaire (exemple un fichier, peu importe la taille), et par une succession de calcul on tire de ce fichier un code de 32 caractères par exemple pour le md5. Ce code obtenu est spécifique au fichier de départ et il est très très peu probable d'obtenir le même code avec un autre fichier. On à donc de cette manière un identifiant unique spécifique au fichier (ou aux données) d'origine.
comment fait-il pour compléter, reprendre ?
doit-il attendre 1/4 d'heure ? ou simplement envoyer un nouveau post ?
Pour l'édition du post, il n'y a aucune contrainte. Une fois que le post possède un identifiant, on peu modifier le contenu sans changer l'identifiant... pas de problème à ce niveau. Et dans le cas d'une modification d'un post, il n'y a pas de risque de multipostage.
ASM wrote:
ASM wrote:
La seule solution propre passe par une base de données
avec clé unique, calculée sur les données entrées par l'utilisateur
(et non pas en auto-incrément).
Oui? tu peux expliquer ?
Lorsque tu reçois le message du client, tu en tire un identifiant
unique, comme par exemple un md5 ou sha.
ha! ha! voilà qui est interressant !
et ne m'éclaire pas du tout !
(je suis une crasse en bdd et en bp d'autres choses)
on va voir ce que nous en dit google.
Le md5 ou le sha, c'est une technique de hashage. C'est à dire que l'on
prend une suite binaire (exemple un fichier, peu importe la taille), et
par une succession de calcul on tire de ce fichier un code de 32
caractères par exemple pour le md5.
Ce code obtenu est spécifique au fichier de départ et il est très très
peu probable d'obtenir le même code avec un autre fichier.
On à donc de cette manière un identifiant unique spécifique au fichier
(ou aux données) d'origine.
comment fait-il pour compléter, reprendre ?
doit-il attendre 1/4 d'heure ?
ou simplement envoyer un nouveau post ?
Pour l'édition du post, il n'y a aucune contrainte. Une fois que le post
possède un identifiant, on peu modifier le contenu sans changer
l'identifiant... pas de problème à ce niveau. Et dans le cas d'une
modification d'un post, il n'y a pas de risque de multipostage.
La seule solution propre passe par une base de données avec clé unique, calculée sur les données entrées par l'utilisateur (et non pas en auto-incrément).
Oui? tu peux expliquer ?
Lorsque tu reçois le message du client, tu en tire un identifiant unique, comme par exemple un md5 ou sha.
ha! ha! voilà qui est interressant ! et ne m'éclaire pas du tout ! (je suis une crasse en bdd et en bp d'autres choses) on va voir ce que nous en dit google.
Le md5 ou le sha, c'est une technique de hashage. C'est à dire que l'on prend une suite binaire (exemple un fichier, peu importe la taille), et par une succession de calcul on tire de ce fichier un code de 32 caractères par exemple pour le md5. Ce code obtenu est spécifique au fichier de départ et il est très très peu probable d'obtenir le même code avec un autre fichier. On à donc de cette manière un identifiant unique spécifique au fichier (ou aux données) d'origine.
comment fait-il pour compléter, reprendre ?
doit-il attendre 1/4 d'heure ? ou simplement envoyer un nouveau post ?
Pour l'édition du post, il n'y a aucune contrainte. Une fois que le post possède un identifiant, on peu modifier le contenu sans changer l'identifiant... pas de problème à ce niveau. Et dans le cas d'une modification d'un post, il n'y a pas de risque de multipostage.
