Y a-t-il une bonne raison pour laquelle je vois VARCHAR(255) utilisé si souvent (plutôt qu'une autre longueur) ?

Question

Dans de nombreux cours, livres et emplois, j'ai vu des champs de texte définis comme VARCHAR(255) comme une sorte de valeur par défaut pour les textes "courts". Y a-t-il une bonne raison pour laquelle une longueur de 255 est choisie si souvent, autre que le fait d'être un beau chiffre rond ? S'agit-il d'une survivance d'un temps passé où il y avait une bonne raison (qu'elle soit ou non valable aujourd'hui) ?

Je réalise, bien sûr, qu'une limite plus stricte serait plus idéale, si vous connaissez d'une manière ou d'une autre la longueur maximale de la corde. Mais si vous utilisez VARCHAR(255), cela indique probablement que vous ne connaissez pas la longueur maximale, mais seulement qu'il s'agit d'une chaîne "courte".

---

Note : J'ai trouvé cette question ( varchar(255) v tinyblob v tinytext ), ce qui signifie que VARCHAR( n ) exige n +1 octets de stockage pour n <=255, n +2 octets de stockage pour n >255. Est-ce la seule raison ? Cela semble un peu arbitraire, puisque vous n'économisez que deux octets par rapport à VARCHAR(256), et que vous pourriez tout aussi bien économiser deux autres octets en le déclarant VARCHAR(253).

Answer 1

255 est utilisé parce que c'est le plus grand nombre de caractères qui peuvent être comptés avec un nombre de 8 bits. Cela permet de maximiser l'utilisation du nombre de 8 bits, sans exiger frivolement un autre octet entier pour compter les caractères au-dessus de 255.

Lorsqu'il est utilisé de cette manière, VarChar n'utilise que le nombre d'octets + 1 pour stocker votre texte. Vous pouvez donc tout aussi bien le définir sur 255, à moins que vous ne souhaitiez fixer une limite stricte (comme 50) au nombre de caractères du champ.

Answer 2

Historiquement, 255 caractères ont souvent été la longueur maximale d'un message de type VARCHAR dans certains SGBD, et il s'avère parfois être le maximum effectif si vous voulez utiliser UTF-8 et avoir la colonne indexée (à cause des limitations de longueur d'index).

Answer 3

Probablement parce que SQL Server et Sybase (pour n'en nommer que deux que je connais bien) avaient l'habitude de limiter à 255 le nombre de caractères dans un fichier de type VARCHAR colonne. Pour SQL Server, cela a changé dans la version 7 en 1996/1997 environ... mais les vieilles habitudes ont parfois la vie dure.

Answer 4

Je vais répondre à la question littérale : pas de il n'y a pas de bonne raison pour laquelle vous voyez VARCHAR(255) utilisé si souvent (il y a en effet raisons (comme indiqué dans les autres réponses, mais pas les bonnes). Vous ne trouverez pas beaucoup d'exemples de projets qui ont échoué de manière catastrophique parce que l'architecte a choisi VARCHAR(300) au lieu de VARCHAR(255). Ce problème serait presque totalement insignifiant même si vous parliez de CHAR au lieu de VARCHAR.

Answer 5

Note : J'ai trouvé cette question ( varchar(255) v tinyblob v tinytext ), ce qui signifie que VARCHAR( n ) exige n +1 octets de stockage pour n <=255, n +2 octets de stockage pour n >255. Est-ce la seule raison ? Cela semble un peu arbitraire, puisque vous n'économisez que deux octets par rapport à VARCHAR(256), et que vous pourriez tout aussi bien économiser deux autres octets en le déclarant VARCHAR(253).

Non. Vous n'économisez pas deux octets en déclarant 253. L'implémentation du varchar est très probablement un compteur de longueur et un tableau non terminé de longueur variable. Cela signifie que si vous stockez "hello" dans un varchar(255), vous occuperez 6 octets : un octet pour la longueur (le nombre 5) et 5 octets pour les cinq lettres.