Reprise du message précédent :
Je conseille aussi de faire un premier iconv pour nettoyer, si utf-8 :

$str = iconv('utf-8', 'us-ascii//TRANSLIT',
            iconv('utf-8', 'utf-8//IGNORE', $str));

Théoriquement, on devrait pouvoir faire les deux d'un coup (//TRANSLIT//IGNORE), mais je sais pas pourquoi, ça foirait chez moi sur le serveur de prod. Les deux séparémment fonctionnent. Le coup du nettoyage est nécessaire en cas de caractères invalides, remplacés par rien, donc zuber-cool

Ok merci

P.S. : PUTAIN J'EN AI MARRE DE BOSSER SUR CE PUTAIN DE SERVEUR DE MES COUILLES AVEC SON MYSQL3 ET SON PHP4 ET SON SAFE_MODE ON §§§§§§§§§§§§ foreach($smileys_en_colere as $smiley_en_colere) echo ''; §§§§§§ /FOU/ /FOU/ /FOU/

strtr('héllo', 'é', 'e');

htmlentities($str, ENT_QUOTES, 'utf-8');

Faut attendre PHP6 pour l'unicode en natif hein
 
Je suis curieux quand même de la raison qui te pousse à devoir virer les accents
Je sens que je vais apprécier
 

Pour faire de belles url... Voici ma fonction actuelle :

public static function makeFriendly($str)
    {
        return
            preg_replace('/-{2,}/', '-',
            preg_replace('/[^a-z0-9-_]/', '',
            str_replace(array(' ', ',', ':', ';', '/'), '-',
            strtolower(
            iconv('utf-8', 'us-ascii//TRANSLIT',
            iconv('utf-8', 'utf-8//IGNORE', $str))))));
    }

 
puis-je soumettre l'idée que faire des opérations de lecture simple sur une base avec un compte admin sur un machin qui fait surement de l'autocommit, c'est quand meme chercher la merde ?

BDD avec 3000 réf de pneus, au lieu de faire un système pour uploader une image pour chacun d'eux, il suffit de le mettre dans le dossier "pictures", sous-dossier de la marque, et le nom du fichier portant le nom du pneu, sans accent, sans caractères spéciaux.

En gros si dans la base on a le pneu Supère-Mark VFS-250-Électrochoc il suffit de mettre une image dans "pictures/superemark/vfs250electrochoc.jpg" pour qu'elle soit affichée automatiquement, avec de l' URL Rewriting qui dit que si le fichier existe pas, il balance le fichier par défaut...

Ça te va ?

Edit : Ah bah en gros ma fonction actuelle ressemble bcp à celle de FlorentG, sauf que je ne laisse ni tirets, ni underscores

Bon ça passe pour cette fois
 
J'ai tellement vu de code crado en PHP que je me méfie maintenant

J'ai rien capté

edit : ah si j'ai presque compris, ben je suis d'accord, menfin ça doit être la troisième fois que je touche a DBDesigner, et la première fois je crois que j'ai pas réussi à me connecter avec autre chose que root, pas pris la tête depuis, donc voila.

 
Ben pour se connecter avec autre chose que root ... faut créer un autre user que root peut-être

ho

Mais d'ailleurs ce débat tombe bien, parce que je capte rien aux autorisations MySQL. Je viens de cloner ma base pour la prod, mais pas moyen de s'y connecter avec l'user que je veux, pourtant j'ai mis toutes une "user permission" et une "database permission", avec le bon mdp et tout... Pourtant ça marchait avec l'user et la base de test...

ca dépend d'où tu veux te connecter aussi.
edit : cf champ host de la table user

bah PHP, donc localhost

edit : nan bah tout va bien, jme suis juste planté de nom d'user En fait j'ai tout compris aux autorisation mysql thx dsl lol mdr a+

Dans les droits de l'utilisateur, tu lui as bien mis "OK" pour la lecture, l'écriture ... ?
S'il a le droit de se connecter mais de rien faire, c'est pas très utile.

edyth

Question "Friendly Url." J'ai besoin de faire un système d'url (voir ma fonction en haut de la page).
 
Alors par exemple pour des news, j'ai des urls style /news/2007/10/11/pouet-tagada-truc.html. L'id de la news n'y est pas présent. Il y a évidemment le risque que si le mec change le titre, l'url ne fonctionne plus.
 
Alors mon idée, c'est qu'à chaque changement de titre (ce qui sera rare je pense), je stocke la vieille url dans une table style "news_oldurls", avec en face la nouvelle, pour rediriger automatiquement.
 
Pensez-vous que c'est chose intelligente, ou est-ce que ce n'est pas la peine de se faire chier pour si peu ? Sachant que je risque d'utiliser ce système pour bien d'autres choses, genre pour un catalogue qui aurait une hiérarchie de catégories...

Une raison particulière pour ne pas inclure l'ID dans l'URL ?

Edit : Et il se passe quoi si tu as 2 fois le même titre ?

Si le gars interverti deux URLs, ils se passent quoi ?  
Si tu ne mets pas l'information pour identifier ta news dans l'url, ça risque forcement d'être plus compliqué.

C'est juste histoire de se faire chier ou il y a une raison ?

Pour avoir les urls les plus clean possible. Si j'ai l'id en plus du titre, y'a risque de duplicate content je crois, vu qu'il y aurait plusieurs url pour accéder exactement au même contenu. Avec une url ultra-unique, pas de problème pour ça. Si le titre change, une redirection 301 pour indiquer à tout le monde la nouvelle adresse
 
 

Pour le cas des news, y'a la date en plus. Pour le reste (genre catalogue), pas de risque d'avoir deux fois la même url, c'est vérifié lors de l'insertion.
 

Moi ça me semble bien, cool URIs don't change

Balle dans la tête, ça lui apprendra à être un gros lourd

En gros l'url stockée devient un second ID quoi ... autant virer l'ID numérique de la base dans ce cas non ?

Utiliser une URL en primary key dans une table, bizarrement je sais pas si c'est optimisé

Se soucier d'optimisation pour la clef utilisée pour indexer des news/posts de blog, bizarrement je pense qu'on s'en tappe

 
Nan mais par exemple si on a la page http://www.mysite.com/news/my_super_news
 
Autant définir "my_super_news" en tant qu'ID

Heureusement que l'URL n'est pas en plus autoincrément.

Oui
 
Enfin non, tu sluggify ton url titre (histoire d'avoir uniquement des caractères ascii, des "-" et des "_" ) et tu utilises ça comme clé

C'est utiliser un id numérique pourri sans aucune relation avec le métier qui est pas optimisé

Ben oui.
 
Enfin non, faut utiliser "my-super-news", parce que google considère "my_super_news" comme un seul mot

Voilà, je pensais surtout à cet article
 

Le problème, c'est que l'url risque de changer... Et j'aime pas modifier la clé primaire Surtout qu'elle devra être utilisée genre pour rattacher à une table commentaires par exemple.

 
Si l'url change c'est que le titre à changé, ça doit pas être des cas fréquent.
 
Titre 1:
Mon super titre => id = mon-super-titre
 
Si le titre change pour :
Mon pas super titre => id reste mon-super-titre
 
Et tu ajoutes dans une table old_urls
'mon-pas-super-titre', 'mon-super-titre'
 
Si on appelle mon-super-titre, et qu'il n'est pas trouvé dans la 1ère table, tu fais un check sur la seconde table, si tjs pas trouvé => 404

 
Anéfé

Ben tu la changes pas, tu crées une nouvelle entrée à la nouvelle clé primaire, et tu flagges l'ancienne comme étant redirigée (ou bien alors tu ajoutes une 2e table -- celle des e.g. HTTP 301, dans laquelle tu stockes des couples (ancienne URL, nouvelle URL), que tu checkes avant de checker ta table principale à chaque accès)

(Notons que dans l'idéal il faut aussi laisser une entrée annihilée dans la première table, genre tu vides tous les champs et seule la clé reste, afin que ta db d'évite de créer un nouveau "post" avec la même clé/le même slug, qui mènerait à des comportements bizarres)

Demande donc aux sites comme jeuxvideo.Fr ou presence-pc le nombre d'URL qu'ils ont et qui ne correspondent plus au titre. On peut s'attendre à ce que ça soit rare quand on a jamais vu ça mais on ne peut pas se baser sur une hypothétique rareté pour choisir les clés primaires et/ou étrangères.

C'est une solution. Maintenant si j'ai par exemple une table "commentaires", ça va pas trop faire lourdingue, le champs "news_parente" qui contient l'url à chaque fois ?

c'est juste une requête à faire pour éditer la PK des commentaires quand un titre est édité

[création du nouvel item post]
[création du redirect de l'ancien post vers le nouveau post dans la table de 301]
[pour chaque comment avec post_id == old_slug, set post_id = new_slug]
[optionnel, vider l'ancien post pour monter qu'il n'existe plus]

Tu fait le tout dans une seule transaction (sauf la dernière étape, qui peut parfaitement être en dehors), personne ne devrait se rendre compte de quoi que ce soit

edit: ou alors tu te simplifies la vie en créant une table de liaison, les comments pointent sur un ID unique (potentiellement numérique) et fixe de la table de liaison, et tu peux faire varier le slug qui lui est associé, comme ça t'as à modifier ton id qu'à un seul endroit, par contre récupérer les commentaires d'un post ou le post d'un commentaire impliqué 3 tables au lieu de 2

Ca j'imagine. Ma question était plutôt du style "un VARCHAR(64) comme PK, lourd ou pas ?"

C'est vrai que les bases en 3ème forme normale c'est super optimisé  

Va te trimballer des foreign key en varchar ça va être rigolo pour les perfs : http://www.mysqlperformanceblog.co [...] /#more-218

Je laisserai un id numérique et ajouterai un index de type unique sur le champ texte en question

Je suis pas un spécialiste des DB, mais il ne me semble qu'une table utilisant un ID numérique sans aucune relation avec le métier est au mieux en 1NF, sûrement pas en 3NF. Au contraire.

Ton lien confirme surtout que MyISAM, c'est vraiment de la merde (pertes de perfs de 550% ), une perte de perfs de 50% pour avoir de vrais IDs et une table normalisée ça me semble pas bien gênant, la dénormalisation tu la vois quand l'appli fonctionne correctement et que tu commences à avoir des problèmes de charge (enfin bon, c'est le classique débat "natural key" vs surrogate key)

edit: sur natural vs surrogate, http://www.bcarter.com/intsurr1.htm

Je parlais de 3NF pour la version avec le texte en PK

Le débat est pas tout récent effectivement
Chacune des solutions a des avantages et des inconvénients.
Avec InnoDb c'est chiant aussi les "natural key", surtout quand ta PK porte sur plusieurs champs car les index reprenne la valeur de la PK pour chaque enregistrement (je sais pas si je suis clair ).
 
Mon lien confirme surtout que MyISAM ça poutre en vitesse quand on sait bien s'en servir

Ah ok, alors on est d'accord. Et personne n'a dit que le 3NF était optimisé (bien au contraire), par contre il y a un adage qui me tient à coeur en informatique: correctness first. Une appli rapide qui donne des résultats faux n'a aucun intérêt.

Appliqué aux DBs, ça pourrait donner un truc du genre: il est toujours possible de dénormaliser...

Tu es clair, et sur ce point, c'est uniquement un problème en termes de tailles (des données), en terme de clarté et en terme de nombre de requêtes l'utilisation de natural keys est supérieur aux surrogates

oui et non.

Oui, il est connu que MyISAM est extrèmement rapide quand on effectue énormément de lectures et très peu de tout le reste. Il est également connu qu'il est impossible de se reposer sur le fait qu'une table MyISAM soit correcte, parce qu'elle n'implémente même pas la base pour une DB (ACID), et qu'énormément de fonctionalités manquent. En d'autres termes, une table MyISAM c'est très rapide quand c'est utilisé comme une flat file indexée. Ce qui est exactement la nature d'une table MyISAM, bizarrement.

Rares sont les fois où j'ai utilisé des clés naturelles...

Selon toi il manque quelles fonctionnalités ?
Ce que je trouve pratique avec MySQL c'est qu'on peut mixer les types de tables utilisées suivant les besoins.
On n'a pas toujours besoin de l'ACID.