Discussion :

[Thierry8]

Bonsoir,

encore moi !
Je connais les différences entre VARCHAR & CHAR, seulement je ne sais pas dire quand est-ce qu'il faut prendre l'un ou l'autre !

En effet CHAR (taille fixe) permet des recherches plus rapides et une sécurité accrue, mais demande plus d'espace. VARCHAR permet quant à lui d'économiser l'espace disque (taille en fonction de la valeur), données réparties et donc plus lent pour les recherches.

En prenant un critère de probabilité à savoir: quel est la probabilité que tel et tel champ fasse tel et tel taille. Pour tout ça ok.

Mais par exemple (exemple simple):
Pour stocker un pseudo je prend un champ de 30 caractères max, sachant que la plupart seront plus petit (à peu près 10 caractères). Mais dans ce cas que faut-il faire la probabilité me dirait plutôt de choisir le VARCHAR pour un gain d'espace disque, mais en réfléchissant le pseudo peu être un critère de selection utilisé souvent, ne faudrait-il pas plutôt priviligier l'aspect "vitesse" ?

Comment faire la différence ?

(en cas d'erreur de ma part n'hésitez pas à me corriger)

[vic]

En fait avec un VARCHAR la taille moyenne utilisée par les index sera plus petite, donc les recherches sur index se feront plus vite que pour un CHAR. De plus il est toujours plus rapide de parcourir une table contenant globalement moins de données.

L'avantage ne va au CHAR que pour des requêtes ne faisant pas appel à un index, et si la taille moyenne des chaines est proche de la taille maximale du champ. Dans le reste des cas le VARCHAR est le meilleur choix.

[Maximil ian]

Oui mais les tables de longueur fixe ont d'autres avantages liés au fait que les blocs de données sont contigüs et de longueur prévisible :

- Pas de fragmentation et moins de risques de corruption
- Reprise après crash plus facile
- Lecture des enregistrements sur le disque plus rapide
- Mise en cache des blocs de données plus simple

[Thierry8]

Bien justement Maximilian, par rapport au problème énoncé avec le pseudo, quel choix ferais tu ? Celui du CHAR, non ?

[Thierry8]

Lorsque je souhaite modifier mon champ varchar en char il m'indique la requête suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER TABLE `administration_site` CHANGE `utilisateur` `utilisateur` CHAR( 30 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL

Donc aucune erreur, mais il reste en VARCHAR...!
Est-ce que quelqu'un peut m'aider...m'expliquer ?

Merci.

PS: Je suis toujours preneur du choix que vous feriez par rapport au problème énoncé sur le pseudo.

[Maximil ian]

Lorsque je souhaite modifier mon champ varchar en char il m'indique la requête suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER TABLE `administration_site` CHANGE `utilisateur` `utilisateur` CHAR( 30 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL

Donc aucune erreur, mais il reste en VARCHAR...!

Il doit y avoir d'autres colonnes de longueur variable (VARCHAR, BLOB, TEXT...) dans la table donc MySQL reconvertit implicitement utilisateur en VARCHAR.

En ce qui concerne ta question, il n'existe pas de choix universel. Si la base est petite, le gain de performances généré par les lignes de longueur fixe sera négligeable par rapport aux inconvénients cités plus haut.

Le mieux serait encore de concevoir des tests pour analyser les deux cas de figure.

[Thierry8]

Effectivement il y a d'autre variable de type VARCHAR !
J'ai tetser avec un CHAR(1) et il reste en CHAR !
Cela signifie que je ne peux mettre un champ de type CHAR dès lors qu'un autre champ est en VARCHAR ! pas très pratique ça !

[Maximil ian]

Là c'est un cas particulier parce que les colonnes VARCHAR d'une taille inférieure à 4 sont implicitement converties en CHAR (en effet pour une colonne si petite les avantages de VARCHAR ne sont plus utiles et on pert un octet pour indiquer la taille).

Cf http://dev.mysql.com/doc/refman/5.0/en/silent-column-changes.html

[Thierry8]

Oui merci (j'ai déjà fais le tour de la doc sur ça ! )
mais je ne comprends tout de même pas !
Un CHAR n'est utilisable que s'il est plus petit que 4 caractères...?!
Donc bien entendue il n'y a presque que des VARCHAR dans une table !...

[pcaboche]

Un CHAR n'est utilisable que s'il est plus petit que 4 caractères...

Ca c'est complètement faux !

Personnellement, j'ai une préférence pour le type CHAR (car de taille fixe) pour des données pas trop longue (n'excédant pas la trentaine de caractères).

Et puis j'imagine que tes pseudos auront une longueur moyenne de 8 à 10 caractères, soit une marge de manoeuvre de 20 caractères seulement... je doute que ça fasse une énorme différence en termes de place au niveau de ta base de données.

Pour d'autres types de champs où la longueur varie beaucoup, le VARCHAR (ou même le TEXT si les champs peuvent être longs) s'impose.

[Thierry8]

euh...je saisie pas tout ! As tu lu tout le post ?
Car je souhaite justement passer mon champ actuellement en VARCHAR de 30 caractères en CHAR, mais PHPMyAdmin ne me fait rien, il le repasse automatiquement en VARCHAR....
Je ne demande qu'une chose c'est pouvoir le faire...

[pcaboche]

Oui, j'en profitais pour donner mon avis sur CHAR/VARCHAR et les pseudo.

Si tu n'y arrive pas, il y a toujours la méthode "bourrine":
- créer une nouvelle table (avec les champs qui vont bien)
- faire un: INSERT INTO nouvelletable SELECT * FROM matable
- supprimer l'ancienne table
- renommer la nouvelle table avec le nom de l'ancienne

Sinon, j'en ai profité pour faire des statistiques sur une base que j'ai en local, voici la requête:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
SELECT 
  AVG( LENGTH(NomUtilisateur) ) AS LongueurMoyenne,
  STDDEV( LENGTH(NomUtilisateur) ) AS DeviationStandard, 
  MIN( LENGTH(NomUtilisateur) ) AS LongueurMini,
  MAX( LENGTH(NomUtilisateur) ) AS LongueurMaxi,
  COUNT(*) AS NombreEnr
FROM utilisateurs

Et voici le résultat:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 LongueurMoyenne  	 DeviationStandard  	 LongueurMini  	 LongueurMaxi  	 NombreEnr
  	7.5331  	  	  	2.5697  	  	 	  	2  	 	  	22  	  	 	4656

Ca donne une idée...

[Thierry8]

Merci !

[Thierry8]

J'ai essayé de créer une nouvelle base:

- quand j'insere uniquement des champs de type char: OK

- dès lors ou j'ajoute un champ de type varchar tous les autres passent aussi en varchar !

[Maximil ian]

J'ai essayé de créer une nouvelle base:

- quand j'insere uniquement des champs de type char: OK

- dès lors ou j'ajoute un champ de type varchar tous les autres passent aussi en varchar !

Oui en d'autres termes c'est ce que je disais :

Il doit y avoir d'autres colonnes de longueur variable (VARCHAR, BLOB, TEXT...) dans la table donc MySQL reconvertit implicitement utilisateur en VARCHAR.

Il faut bien voir qu'il n'y a gain de performance que quand la ligne est entièrement de longueur fixe, c'est à dire lorsque toutes les colonnes qui la composent sont de longueur fixe.
C'est pourquoi MySQL convertit toute la ligne en variable (sauf les CHAR de moins de 4 caractères) lorsqu'on introduit au moins une colonne de longueur variable.

If any column in a table has a variable length, the entire row becomes variable-length as a result. Therefore, if a table contains any variable-length columns (VARCHAR, TEXT, or BLOB), all CHAR columns longer than three characters are changed to VARCHAR columns.

[Thierry8]

OK ! très bien je n'avais pas compris cela !
Maintenant c'est plus clair. Merci.