Reprise du message précédent :
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

Tu compares la PK dans les deux cas, c'est strictement la même chose.

Si le pseudo est modifié, il est modifié partout, je vois toujours pas le problème.

toi tu sors, steuplé.

 
Oui enfin il y a fort à parier qu'il faudra de toute façon une jointure sur la table user pour d'autres données...
 
Et puis parlons des URL également, tu fais comment avec un pseudo qui comprends des accents, tiret ou je ne sais quoi encore ?
 
Je préfère :  
 
/voir-profil-25/l-elephant-bleu.html
 
à :
 
/voir-profil-L%5C%82l%82phant+%22bleu%22

tiens j'ai un exemple : une table de categories qui serait identifiée par le nom de la categ, c'est vrai que pour le coup ça parait pas mal de foutre le nom en PK plutôt que faire un autoincrement

mais, toujours le même bouzin, avec un id autoincrement, pas de soucis pour modifier le nom d'une categ

Tu préfères un truc qui veut rien dire à un truc encodé

Tu crées une nouvelle cat avec le nouveau nom, tu rebind tous les anciens trucs dessus et tu supprimes l'ancienne cat maintenant vide, je vois pas où est le souci, et t'as des tables lisibles

pas de soucis particulier, c'est juste plus lourd à faire (enfin, quelques lignes de code en plus quoi )

fin bon, dans tous les cas les deux méthodes se défendes

je propose un sondage autoincrement vs varchar

C'est lourd à exécuter, mais à faire pas vraiment.

une clé naturelle c'est pas nécessairement un varchar, et c'est pas nécessairement une clé simple non plus

Et le nom de la catégorie, t'es absolument sûr que t'auras pas le même ailleurs genre dans un autre sur-catégorie (style : "Divers" ) ?
Là faudra faire une PK composite ?

perso je voterais autoincrement
Le mec qui a pas assez d'expérience va faire de la merde avec des clés naturelles une fois sur 2

je prend des racourcis j'avais juste la flem d'écrire clé naturelle, trop long, ouai pour le coup c'est raté

spa faux
 
enfin perso j'ai jamais utilisé autre chose que des autoincrément, je pense que ça m'emmerderais bien une clé naturelle, à part dans quelques cas ou c'est judicieux, genre l'histoire des départements, des codes postaux etc...

idem, j'ai du mal à concevoir autrement, j'suis vraiment étonné qu'il y ai autant d'adeptes des clés naturelles !

Sinon il y a deux autres choses qui me gènent avec les clés naturelles :

- Pas de notion de chronologie (ok, on peut mettre un auto-incrément à côté... ou un champ date, mais avec MySQL faut la rentrer à la main)
- Le schéma de chaque table est propre à elle-même : avec des auto-inc, t'as un champ "id", tout le temps sauf rare exception, et le champ qui s'y réfère est "table_id". C'est prévisible et instinctif. Avec des clé naturelles généralisées faut avoir un schéma sous les yeux ou en tête.

Ouais non là, si tu sous-entends que tu te bases sur un ID auto-increment pour connaître la date d'un enregistrement, excuse-moi mais c'est méga-crade Sans compter que dans le meilleur des cas t'as pas d'autre info que "cette ligne a été insérée avant celle-ci". Si tu veux faire de l'audit sur une table, faut penser la structure de la DB en conséquence, pas se baser sur des bidouilles

 

D'un coté t'as clé + libellé qui ne correspond à rien pour faire joli, de l'autre tu mets juste la clé.
Genre ton libellé sert à quelque chose.
Sur ton exemple le mec qui voit l'url va vouloir faire /voir-profil-25/toto.html et se retrouvera sur le profil de l'éléphant bleu, alors qu'avec une clé naturelle il tentera peut-être /voir-profil-toto avec succès.
 
 

 
Pourquoi? ça change quoi dans ta façon de coder?
 

 

Si tu veux de la chronologie tu stockes un champs date dédié, tu te bases pas sur un identifiant à la mord moi le noeud.
 

 
quoi ça généralisées? tu utilises des clés naturelles là où ça a un sens, c'est tout. Une clé naturelle doit justement être comprise naturellement parce-que l'utiliser comme identifiant a du sens et parait logique.

Jusqu'au jour où tu commences à recycler tes IDs, et là ta chronologie tu peux te la mettre dans l'os
 
Si t'as besoin de faire des chronologies, tu passes par un champ datetime, pas par un truc qui ne fournit pas la moindre garantie chronologique.

Tu codes des FK sans savoir quelle table tu lies toi

Non je ne sous-entends pas ça

Simplement, quand tu dev/débugge avec un client BDD à côté de toi, les IDs permettent facilement de voir la ligne qui vient d'être insérée (l'id le plus grand, quoi), l'ordre dans lequel c'est fait, et même de voir si une ligne a été supprimée (quand un auto-increment manque )

Effectivement, mais j'ai jamais été jusque-là
Ya vraiment encore des nouvelles applis qui le font ?

Savoir, oui, me souvenir instantanément de sa structure, pas forcément.

 
Je sais même plus quoi répondre...tu considères vraiment ça comme une justification d'utilisation d'un auto incrément?

Le fait de diviser mon temps de dev par 2 ? oui.

en mettant de l'auto-incrémenté partout?
Arrête de nous prendre pour des truffes, merci

Bah entre le temps de design en plus, le temps de dev qu'il faut pour pouvoir modifier les clés naturelles, la perte en prévisibilité de la structure des tables, la maintenance en plus, les vérifs d'unicité, et autres, c'est pas entièrement impossible

mauvaise foi de platine.

En tout cas 4 pages de débats pour ma question initiale .. ca me rassure elle était pas trop dumb  
j'ai appris pas mal de choses

Oui youpi bravo, si tu veux jouer, remplacer le pseudo par un titre d'article par exemple.

Mes excuses, mais rien que pour le référencement, je préfère un /article-5/titre-de-mon-article.html oui.

Edit : Quant au slug, je fais une redirection voire une 404 quand il est pas bon

Ah mais oui un titre d'article ça rentre EXACTEMENT dans les cas qu'on a pu citer comme candidats à la clé naturelle...

...et pourtant ça ne t'empêche toujours pas de faire la même chose, putain de bordel de merde! Ce sera juste article-mon_titre_urlencode/mon-joli-titre-pour-google...

...et pour ta redirection 404, lolzor. Ton autoincrément te simplifie tellement la vie que t'es obligé de vérifier si un second input de l'utilisateur matche bien une version "cleanée" d'un autre champ de la même table...superbe!

Oué bon je me suis viandé
 
Quant au fait de vérifier un des paramètres de l'url pour savoir si elle est correcte ou pas, je ne vois pas le problème.

Skuze moi mais niveau référencement elle est où la différence entre /article-5/titre-de-mon-article.html et /titre-de-mon-article exactement

non, tu en vérifies un par rapport à un autre, c'est différent.
Après je supposes que tu ne différencies pas le cas où l'id n'existe pas du cas où l'id et le libellé ne correspondent pas, mais potentiellement tu gagnes un traitement d'erreur.

Avec le premier t'es positionné sur le mot clé "5", qui est nettement plus intéressant que "titre" ou "article" :
http://www.google.com/trends?q=5%2 [...] all&sort=0
CQFD

bien joué

Question suivante !

Utiliser jasper reports via php, quelqu'un a déjà fait? Pour/contre, pourquoi?

Y en a qui bossent sur des Mac Mini Servers ? Feedback ? (pas de troll plize )

Ca fait même pas une journée qu'ils sont sortis, c'est un peu tôt pour poser la question

Et le MMS est pas fait pour bosser dessus, c'est fait pour servir de service handler dans les petites boites (10~20 personnes) en full mac: serveur iCal, Mail, Address Book, …

C'est sous-estimer Masklinn

 
Qu'est ce qui empeche de s'en servir comme serveur de pré-prod ? Ou de développer dessus des applications web intranet ?  

Tu peux avoir mieux pour moins cher.

Mieux à quel niveau ?