Reprise du message précédent :

Non mais c'est quoi ta définition de "header('Location: mapage.php') ne marche pas", alors? Il se passe quoi exactement?

bah, il redirige pas vers mapage.php    
 
la page ou ya le header, je valide mon form, j'insert en base, si c'est ok, je fais un header
tout est bien ok, il va bien dans le if de mon header, mais le header ne fait rien, si je fou un die derrière, page blanche

rien dans firebug ?
pareil avec un autre navigateur ?

 
J'aimerais bien savoir comment vous faites pour être sûr, à 100%, que les données saisies par l'utilisateur sont absolument correcte et exemptes d'erreurs.

je crucifie le premier qui se trompe
 
ou alors, je fais TOUJOURS un formulaire de modif des donées utilisateurs

Ce qui implique qu'aucune donnée utilisateur n'est unique et fiable dans le temps !

ok, j'crois que c'était une erreur js qui faisait foirer le header
 
Par contre, j'étais loins d'imaginer que du js pouvait faire péter une fonction comme ça

Sur un SIRET c'est pas très dûr, SIREN comme SIRET sont autovérifiants, si la base est codée correctement il y a 9 chances sur 10 pour qu'un SIRET mal saisi soit un invalide et donc détecté avant d'être entré en base
 
Pour le reste, rien n'empêche de prévoir un moyen d'éditer le truc

Si c'est pas unique, c'est par définition pas suffisant pour être une clé primaire.

j'espère que tu veux dire "stable" ici, pas "fiable".

Oui, ça évite bien des erreurs de saisies, effectivement.
Mais j'ai demandé comment tu fais pour être ABSOLUMENT SÛR, à 100%, des données !?
 
Je peux quand même rencontrer les problèmes genre saisie d'un siret d'une entreprise pour l'entreprise qu'était juste en dessous dans le listing ! Le N° sera valide, mais on aura quand même une erreur de saisie.

Là, on parle de SIRET. Un SIRET, c'est unique. Donc selon toi, suffisant pour être PK.
 

Oui, stable.

Tu peux jamais, faut jeter toutes les BDDs à la poubelle, ça sert à rien de stocker des données, suicidons nous pendant la prochaine éclipse
 
  Au niveau quantique tu sais même pas ce que tu stockes exactement, oscour  
 
  Et si un rayon galactique touche ton disque dur ça peut changer les données qui sont dessus, on va tous mourir

Et?

Dans ce cas elle vient d'où ton objection exactement? Si le problème de non-unicité vient d'une saisie incorrecte l'utilisateur sera averti que le numéro a déjà été rentré et ira corriger son erreur, il est où le problème?

Et?

Effectivement, on en peut jamais être sûr des données utilisateurs. C'est pour ça qu'une PK générée automatiquement par le SGBD est meilleure.
 

Que la PK devra être modifiée, ce qui est contraire à sa définition première.

C'est quoi vot' débat de 4 pages et le pb des ID autogénérés en résumé ?
 
Quel est le pb de l'ID autoincrémenté ... parce que j'ai du mal à comprendre...
 
C'est pour vous la jouer SFR ? "Chez nous, vous êtes bien plus qu'un numéro" ou bien ?

Aucun problème si c'est adapté à la situation. De la même manière qu'il n'y a aucun problème avec une clé naturelle dans les situations qui s'y prêtent.

Ben vous m'insulter quand je dis qu'on n'est pas à l'abri d'une erreur de saisie !

j'ai un soucis,  
 
je suis avec jquery,  
j'ajoutes dynamiquement en ajax du contenu (div avec infos) dans ma page,
 
j'aimerais pouvoir mettre une image dans le contenu chargé en ajax, avec une classe, pour lancer un evenement lorsqu'on clique dessus,  
 
un bete

 
mais jquery du coup ne semble pas aimer, il ne doit pas ajouter le contenu à sa liste d'elements avec "class" comme classe,  
 
vous comprenez la ou je veut en venir ?
est-ce possible de faire cela ?

 
http://docs.jquery.com/Events/live

Après c'est juste plus ou moins relou.

Exemple : je gère depuis 3 ans une BDD contenant des morceaux (de musique). Si j'avais voulu faire une clé naturelle, j'aurais utilisé l'ISRC (code unique mondial), admettons que je vérifie son intégrité et tout pour éviter les erreurs, super. Sauf qu'au bout d'un an ou s'est rendu compte que certains morceaux indépendants pouvaient ne pas avoir d'ISRC. J'ai eu aucun changement à faire.

De même j'ai des artistes qui ont des noms. Au départ je me disais qu'évidement ce nom serait unique (edit : bon en vrai non, mais un autre aurait facilement pu le penser), d'ailleurs je l'ai quasiment utilisé comme PK (en version crado). Seulement non, au bout de 30000 albums, t'as 2 artistes qui ont le même nom. Etc...

Tu vas me dire, t'avais qu'à prévoir, mais de 1) l'erreur est humanum et de 2) pourquoi se casser le truc à tout prévoir alors qu'avec une PK générée ya rien à prévoir

 
On n'est pas à l'abri d'une explosion nucléaire non plus.
Une clé naturelle va être souvent ce qui servira à l'utilisateur pour identifier l'enregistrement jusque dans l'interface de ton application. S'il est trop con pour faire attention à ce qu'il saisit dans les tables de référence il mérite de ressaisir.

Non, c'est juste qu'il faut "simplement" tout implémenter pour prévoir ce cas-là, et ainsi avoir la satisfaction d'avoir des clé naturelles parce c'est plus propre ©

On n'est plus au temps des applic de gestion old school quand il fallait effectivement se rappeler des codes à saisir !

Une clé naturelle ne sera pas forcément perçue comme un code, justement parce-qu'elle est naturelle.

tiens j'avais jamais vu ce live   moi j'me faisais chier à ajouter des .click ou autre dans les onsuccess    
 

 
niquel, merci  

C'est vrai, c'est tellement naturel de saisir le N° Siret d'une entreprise plutôt que sa raison sociale. Ou l'ISBN d'un bouquin plutôt que le titre !
 
Ouais, je sais, il faut que la situation s'y prête.
 
Sur ce, je vous laisse. Ciao bye !

Faut arrêter avec les bigint. Déjà pour saturer un int unsigned faut y aller (et si tu arrives à ce point c'est que t'as géré plein d'autres pb d'archi avant)

Cet été on a ajouté toute une nouvelle dimension dans l'ensemble de nos applis, on a du péter les PK naturelle (sur 2 champs) pour la passer sur 3 avec propagation dans toutes les FK. Au final on va repéter le truc pour mettre un autoinc et un index unique et ça va vachement faciliter la maintenance et les jointures.

 
Une fois tous les 3 siècles en gros ?

Ouais mais quand tu utilises des clés naturelles tu vas avoir direct de gros trucs, pour le SIRET par exemple ça va pas rentrer dans un unsigned int (d'un autre côté t'es pas du tout censé le stocker dans un unsigned int) vu qu'il y a 14 chiffres et que tu ne peux en faire rentrer que 10 dans 2**32 (et encore)

 
En même temps en 4 pages, le peu que j'ai vu, c'est que vous avez trouvé l'exemple du SIRET ...
 
Donc à la rigueur, filez voir un petit paquet d'exemples dans lesquels la clé naturelle serait plus appropriée que la clé auto générée non ?

Je parlais d'un unsigned int en autoinc

 
On peut reprendre au hasard les membres d'un forum comme suggéré plus haut...qu'est ce que la clé auto-incrémentée apporte réellement par rapport au login?
Perso je travaille sur des étudiants, quel est l'intérêt de ne pas les identifier par le numéro inscrit sur leurs cartes d'étudiants?
Si t'as une table de départements, quel est l'intérêt d'utiliser un autoincrément qui va te donner autre-chose que le numéro connu de tous?
Etc etc etc etc...

L'adresse e-mail, le login, ...
Moi ça me choque pas plus que ça
Maintenant, je comprends bien la précaution du PK auto-increment

 
Donc à chaque ajout de topic/post/mp etc. enregistrer le login à chaque fois ?
 
INSERT INTO post ... VALUES ... , content = "Mon super message", username = "Dj Super Pepito d'la tanche molle ---" ...
 
Perso ça me choque... c'est pas invalide, certes, mais je trouve ça franchement crade.
 
Pour le cas des départements là OK, c'est déjà plus logique oui.
 

 
Pour le login, voir au dessus, et pour l'email je trouve ça aussi crade.
 
Alors dans la "logique" y'a peut être pas de problème, mais au delà de ça ...
 
Bon après chacun fait comme il le sent

En quoi il est crade de stocker le créateur du topic?  
 
Tu trouves vraiment que INSERT INTO post … VALUES …, content="Whateve", user_id=42 c'est magiquement moins crade

 
Je vois pas ce que ça a de plus crade de faire "insert into post (userId, message) values ('dj yell', 'Mon super message')" que "insert into post (userId, message) values (2125456, 'Mon super message')".
Et cadeau bonux, à la relecture tu as pas besoin d'aller chercher le nom de ce putain d'user 2125456, puisque tu l'as déjà.

 
Ah ben franchement oui, personnellement je trouve ça largement moins crade... Et puis le coup de l'update à chaque changement de pseudo, même si ça n'arrivera pas souvent... bof.
 
Un ID autogénéré, on le change jamais et basta... quel intérêt de travailler sans.
 
Enfin encore une fois, je ne veux convaincre personne, et je m'en tape, mais vu que dans la majorité des cas ça sera de l'ID autogénéré, je ne vois pas de raison d'utiliser autre chose dans quelques cas particuliers.

Parce que faire une jointure pour la moindre pauvre requête portant sur un couple username/post, ça a plus de sens ?
Et puis honnêtement, je t'avoue que la gueule des logins n'influe pas trop sur la beauté du code. Le username peut être "sucemabite", c'est pas mes petites mimines qui vont aller l'écrire à chaque fois dans la bd

Bin si il est sensé pouvoir éditer son message, pour vérifier son identification, suffit de comparer l'ID, là faut comparer le pseudo qui risque d'etre modifié !

chelou ces gens qui utilisent pas plein d'id