Posted August 23, 200420 yr quel est le type de données à mettre pour enregistrer du texte accentué? (jeu de caractère fr).
August 23, 200420 yr Ca dépend de ce que tu dois stocker. varchar 255 si ca passe pas les 256 caractères sinon t'as le choix => blob, text, longblob, longtext A toi de voir selon tes besoins.
August 23, 200420 yr Author un truc que je trouve bizarre aussi c'est que CHAR est toujours insensible à la casse, tandis que VARCHAR BINARY ne l'est pas. Me tromperais-je? Il me faut aussi un champ qui soit sensible à la casse.
August 23, 200420 yr un truc que je trouve bizarre aussi c'est que CHAR est toujours insensible à la casse, tandis que VARCHAR BINARY ne l'est pas.Me tromperais-je? Il me faut aussi un champ qui soit sensible à la casse. Qu'est-ce que tu racontes là. C'est stocké en l'état ou tu l'inserts dans la db, la casse n'intervient que via la fonction que tu appelles. Par exemple (je suppose que tu utilises php) substr_compare te demande si tu veux qu'il vérifie le case sensitive ou non. Bref, dans la db c'est tj stocké de la même maniere dont tu fais ton insert, après a toi d'utiliser la bonne méthode pour faire ta recherche. CHAR c'est en fait un Byte(256) qui stocke le code ascii de ton entrée. Y a aucune différence avec le varchar qui est en fait un char[array] de la longueur que tu lui définis. Edited August 23, 200420 yr by SyGEN
August 24, 200420 yr pour MySQL, les probleme de casse, il ne s'en preocupe pas. donc, rechercher Coucou,COUCOU, CoUcOu,... revient au même si dans ta db tu as enregistré des caracteres. Si tu as enregistré en binaire, ton texte devient un numero et quand tu rechercheras, MySQL recerchera les entrées qui corespondent a la clé mise dans le format de la colonne donc du binaire. donc Coucou est different de coucou! Edited August 24, 200420 yr by warzi
August 24, 200420 yr pour MySQL, les probleme de casse, il ne s'en preocupe pas. donc, rechercher Coucou,COUCOU, CoUcOu,... revient au même si dans ta db tu as enregistré des caracteres. Si tu as enregistré en binaire, ton texte devient un numero et quand tu rechercheras, MySQL recerchera les entrées qui corespondent a la clé mise dans le format de la colonne donc du binaire. donc Coucou est different de coucou! Des fois je me demande si tu te relis! qu'est-ce que tu veux comprendre a ce que tu viens de dire... relis toi !! Moi je dirais plutot en clair, un select * from where ne te rameneras pas le case sensitive, mais comme je l'ai dit plus haut, les fonctions php que tu vas utiliser elles vont correctement traiter ton resultset. Et le binary me fait pas rire, comment tu crois qu'il stocke le caractère sinon en byte()char même si tu ne met pas le mot clé binary?! Edited August 24, 200420 yr by SyGEN
August 24, 200420 yr oui je me relis et je comprend toujours ce que j'ai ecris "Moi je dirais plutot en clair, un select * from where ne te rameneras pas le case sensitive, mais comme je l'ai dit plus haut, les fonctions php que tu vas utiliser elles vont correctement traiter ton resultset." donc MySQL ne gere pas la cesse on est bie d'accord "Et le binary me fait pas rire, comment tu crois qu'il stocke le caractère sinon en byte()char même si tu ne met pas le mot clé binary?!" je pense que tu confonds stockage(plein de bits) et representation en memoire (caractères, codes hexadecimaux,...)
August 24, 200420 yr Author http://www.vulgarisation-informatique.com/article_134.php En fait c'est cette page que j'ai regardé, mais il est pas marqué si ça prend en compte les accents ou non.
August 24, 200420 yr oui ca prend en compte les accents ... tous les formats de texte les prennent en compte
August 25, 200420 yr Pour stocker du gros texte, prends un blob, il est bon, prend la casse en compte (contrairement a son homologue text). Mais par contre il me semble que TEXT prend en charge les recherches en full text avec mysql : tu fais une recherche (avec une chaine) et il te classe les résultats par ordre de pertinence... enfin voila
Archived
This topic is now archived and is closed to further replies.