Bonjour,
 
ma question du jour est simple. J'ai une bdd MySQL et dans une de mes tables, je rajoute un champs texte. Je veux prévoir au cas où il sera renseigné avec un texte assez long, donc je mets longueur 500 (c'est un peu exagéré mais je prend pour exemple, la moyenne des valeurs est de disons 50 caractères). Est-ce que je perds en performance à mettre une telle longueur?
sinon autant prévoir large
 
merci

Sans connaitre la réponse exacte à ton probleme (faudrait voir si le type texte ne prend en mémoire et sur le dur que la taille réelle de la valeur stockée mais ca je ne le sais pas sur mysql ), il vaut mieux en principe prendre suffisament que large.

Normalement, il n'y a pas de problème. MySQL (tout comme Oracle et la plupart des autres SGBD) ne prendra que le minimum d'espace. La taille indiquée est une taille maximale, mais derrière le SGBD peut stocker ses données comme il l'entend et avoir des longueurs variables. C'est ce qui arrive avec les champs de type VARCHAR (VAR veut dire longueur variable). Pour ce qui est de la vitesse, il n'y a pas de souci non plus à avoir.

Merci bien . Bah alors je vois pas pourquoi on s'entete à mettre une limite. Autant toujours mettre des varchar de 1000 par exemple  

Pour avoir un modèle cohérent, pour éviter les excès...mettre un champ adresse à 1000 c'est bien joli, mais si tu as des malins qui s'amusent à stocker 1000 caracteres pour leurs adresses, ca te fera des octets en plus pour rien. Par contre je viens de me balader un ptit peu, et le type Varchar me semble être limité à 255 caractere sous MySQL, ensuite c'est du TEXT qui marche sensiblement de la même maniere (dis moi si je me trompe )

Ouais il me semble que c'est ça. Mais je mettrais pas ma main à couper, on sait jamais. je connais pas fond à      

Précisions :
 
varchar :
- Le SGBD utilise en effet la taille de la donnée et non celle de sa déclaration pour stocker dans le fichier de base. Cependant, au cas où tu fasses un update de la première ligne dans le fichier de 'a' vers 'abcdefghijklmnopqrstuvwxyz' le SGBD n'a pas trop envie de redécaller toutes les données du fichier... DONC, il va, à interval régulier, laisser des trous dans le fichier, lui permettant de ne décaller qu'un nombre réduit de données en cas de changement de taille d'une valeur.
Si tu n'as que des varchar(50), alors les tous seront petits, et si tu as des varchar(8000), tu auras des trous énormes... Un fichier avec le moins de trous possibles est évidement plus performant.
-> La taille d'un varchar n'a donc que peut d'importance, cependant, il vaut mieux se contenter de mettre une taille cohérente, qui n'éxcèdera pas la taille maximale.
 
Le type TEXT (ou NTEXT, IMAGE, BLOB, CLOB, MEMO etc.) ne marche PAS DU TOUT de la même façon.
Un champ de se type est en réalité un simple INT32 dans le fichier de données.
Ensuite, un espace réservé pour les valeurs de ces types stockes les valeurs à la façon d'un système de fichier : le INT32 fait référence à une adresse dans le fichier, et les données sont stockées en "RAW" à partir de cette adresse.
Pour cette raison :
- Tant qu'on n'appelle pas ces champs dans une requête (sauf pour la lecture), un TEXT n'impacte pas du tout la performance du SGBD, puisqu'il n'est pas dans la zone des données (pas de perte de place, ni présence de trous)
- Dès qu'on touche à ces champs dans une requête, là c'est la cata : déjà, ces champs n'ont pas de limite de taille. Certains SGBD acceptent jusqu'à 64 Go de données pour un tel champ. On imagine ce que donne un LIKE dessus ... D'autant qu'ils sont répartis de façon totalement anarchiques dans la zone qui leur est réservée (comme des fichiers sur un HD) et ne sont pas indexables (avec des index classiques tout du moins). De la même façon, la plupart des fonctions sont désactivées sur ces types (pas de LIKE par exemple)
 
Par contre, les champs TEXT gagnent énormément à être utilisés avec les index de type "recherche sur texte intégrale" et ne posent donc aucun problème de performances (et même offre de meilleurs perfs que des VARCHAR) dans ce genre d'utilisation. On réserve donc ces champs au stockage de documents dont le type MIME est reconnu par le moteur d'indexation, ou de texte kilométrique. Jamais pour des attributs genre "adresse" ou "nom". Ca peut aussi servir à stocker des fichiers (des images, des vidéos ou autres) mais pour ces cas précis, qui ne tirent pas profit de l'indexation, je trouve qu'il faut mieux passer par le système de fichier et utiliser un varchar pour les localiser sur le disque.
 
Voilà voilà.