CHAR(n) => respecte de la longueur dont n caractères stockée même si la longueur du texte est inférieure à n, il y aura alors un remplissage à blanc.
Exemple "toto" en CHAR(12) donne "toto "
VARCHAR(n) => longueur variable avec au maximum n caractères stockée + stockage de la longueur du texte (e général sur 2 octets) et pas de remplissage à blanc.
Exemple "toto" en VARCHAR(12) donne 04"toto"
AVANTAGES / INCONVÉNIENTS :
VARCHAR économise de l'espace si la longueur des données peut être grande et la taille du texte très fluctuante. Or l'espace économisé se sont des performances en plus.
Mais si la données est voisine de la taille max ou fais toujours la taille max, alors avec les 2 octets pour stocker la taille c'est le contraire qui se produit.
Par exemple pour un code postale, c'est stupide car il y aura toujours 5 caractères (en France) => VARCHAR = 7 octets, CHAR = 5 octets
En sus, la recherche d'une colonne VARCHAR est plus complexe que la recherche d'une colonne chat au sein de la ligne composant la table. Son accès est donc plus lent, car il faut parcourir toutes les colonnes précédentes du fait de la longueur variable.
Enfin, lors des mises à jour la fragmentation du VARCHAR peut devenir très pénalisante. En effet si j'ai stocké "toto" dans un VARCHAR(16) qui va être enchâssé dans la ligne, comment puis-je le faire passer à "taratata" dans une UPDATE ? Il n'est plus possible de la laisser à cet emplacement qui est trop court. Il va donc falloir déplacer soit la ligne complète (si la table n'est pas clusterisée) soit la colonne si la table est clusterisée, et dans tous les cas cela génère de la fragmentation qui est très préjudiciable aux performances.
C'est pourquoi lorsque l'on modélise des données, il faut étudier les types de données avec soin, en sachant quels vont être les traitements, la volumétrie...
J'ai fait une entrée de mon blog en sus sur le sujet :
http://blog.developpez.com/sqlpro/p9...el-difference/
A +
Partager