La règle générale est de choisir CHAR si toutes les lignes sont proches de la même longueur . Choisir VARCHAR (ou NVARCHAR ) lorsque le la longueur varie de manière significative. CHAR peut également être un peu plus rapide parce que toutes les lignes sont de la même longueur.
Cela varie selon l'implémentation de la base de données, mais en général, VARCHAR (ou NVARCHAR ) utilise un ou deux octets de stockage supplémentaires (pour la longueur ou la terminaison) en plus des données proprement dites. Ainsi (en supposant que vous utilisiez un jeu de caractères d'un octet), stocker le mot "FooBar"
-
CHAR(6) \= 6 octets (pas de frais généraux)
-
VARCHAR(100) \= 8 octets (2 octets de surcharge)
-
CHAR(10) \= 10 octets (4 octets de déchets)
Le résultat est le suivant CHAR peut sea plus rapide et plus efficace en termes d'espace pour les données de longueur relativement identique (à deux caractères près).
Nota : Microsoft SQL a 2 octets de surcharge pour un VARCHAR. Cela peut varier d'une base de données à l'autre, mais en général, il y a au moins 1 octet de surcharge nécessaire pour indiquer la longueur ou la fin de vie d'un VARCHAR.
Comme l'a souligné Gaven dans les commentaires : Les choses changent lorsqu'il s'agit de caractères multi-octets et c'est un cas où VARCHAR devient un bien meilleur choix.
Une remarque sur la longueur déclarée de la VARCHAR : Parce qu'il stocke la longueur du contenu réel, il n'y a pas de perte de longueur inutilisée. Ainsi, en stockant 6 caractères dans _VARCHAR(6), VARCHAR(100), o VARCHAR(MAX)_ utilise la même quantité de mémoire. Pour en savoir plus sur les différences entre l'utilisation de VARCHAR(MAX) . Vous déclarez un maximum size en VARCHAR pour limiter la quantité stockée.
Dans les commentaires AlwaysLearning a souligné que la Documentation Microsoft Transact-SQL semblent dire le contraire. Je pense qu'il s'agit d'une erreur ou, du moins, que la documentation n'est pas claire.
