[MYSQL] champ de texte

[serik]

quel est le type de données à mettre pour enregistrer du texte accentué? (jeu de caractère fr).

[SyGEN]

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.

[serik]

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.

[SyGEN]

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.

[warzi]

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!

[SyGEN]

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?!

[warzi]

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,...)

[serik]

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.

[warzi]

oui ca prend en compte les accents ... tous les formats de texte les prennent en compte

[ubik]

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