Existe-t-il une bonne raison pour que je vois VARCHAR (255) utilisé si souvent (par opposition à une autre longueur)?

Question

Dans plusieurs cours, livres et travaux, j'ai constaté que les champs de texte définis en tant que VARCHAR (255) étaient le type par défaut de & "shortish &"; texte. Existe-t-il une bonne raison de choisir une longueur de 255 aussi souvent, mis à part le fait d'être un joli chiffre rond ? S'agit-il d'un passé ancien où il y avait une bonne raison (que cela s'applique ou non aujourd'hui)?

Je me rends bien compte qu’une limite plus stricte serait plus idéale si vous connaissez en quelque sorte la longueur maximale de la chaîne. Mais si vous utilisez VARCHAR (255), cela indique probablement que vous ne connaissez pas la longueur maximale, mais qu’il s’agit d’un & "Shortish &"; chaîne.

Remarque: j'ai trouvé cette question ( varchar (255) v tinyblob v tinytext . ), qui indique que VARCHAR ( n ) nécessite n +1 octet de stockage pour n < = 255, n +2 octets de stockage pour n > 255. Est-ce la seule raison? Cela semble un peu arbitraire, car vous ne sauvegarderiez que deux octets par rapport à VARCHAR (256), et vous pourriez tout aussi facilement sauvegarder deux autres octets en le déclarant VARCHAR (253).

Answer 1

Historiquement, 255 caractères ont souvent été la longueur maximale d'un VARCHAR dans certains SGBD. Il arrive parfois que le maximum effectif soit utilisé si vous souhaitez utiliser UTF-8 et que la colonne soit indexée (en raison de la longueur de l'index). limitations).

Answer 2

255 est utilisé car il s'agit du plus grand nombre de caractères pouvant être comptés avec un nombre à 8 bits. Il maximise l’utilisation du nombre de 8 bits sans nécessiter de manière frivole un autre octet entier pour compter les caractères supérieurs à 255.

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

Answer 3

Probablement parce que SQL Server et Sybase (pour en nommer deux que je connais bien) avaient un maximum de 255 caractères dans le nombre de caractères d’une colonne VARCHAR. Pour SQL Server, cela a changé dans la version 7 en 1996/1997 ou à peu près ... mais les vieilles habitudes ont parfois la vie dure.

Answer 4

Je vais répondre à la question littérale: non , il n'y a pas de bonne raison que VARCHAR (255) soit utilisé aussi souvent (il existe effectivement de raisons , comme indiqué dans les autres réponses, mais pas les bonnes). Vous ne trouverez pas beaucoup d'exemples de projets ayant échoué de manière catastrophique car l'architecte a choisi VARCHAR (300) au lieu de VARCHAR (255). Ce serait un problème d'insignifiance presque totale, même si vous parliez de CHAR au lieu de VARCHAR.

Answer 5

Lorsque vous dites 2^8 vous obtenez 256, mais les nombres en termes d'ordinateurs commencent par le nombre 0. Alors, alors vous avez le 255, vous pouvez le sonder dans un masque internet pour l’IP ou dans l’IP même.

11111111 = 255 est la valeur maximale d'un entier de 8 bits: <=>

Est-ce que cela vous aide?

Answer 6

  

Remarque: j'ai trouvé cette question   (varchar (255) v tinyblob v tinytext),   qui dit que VARCHAR (n) nécessite   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 ne seriez que   économiser deux octets par rapport à   VARCHAR (256), et vous pourriez tout aussi bien   économiser facilement deux autres octets par   en le déclarant VARCHAR (253).

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

Answer 7

Un numéro non signé sur 1 octet peut contenir la plage [0-255] incluse. Donc, quand vous voyez 255, c'est surtout parce que les programmeurs pensent en base 10 (vous avez la blague?):)

En fait, pendant un certain temps, 255 était la taille la plus grande que vous puissiez attribuer à VARCHAR dans MySQL. Il existe des avantages à utiliser VARCHAR sur TEXT avec l’indexation et d’autres problèmes.

Answer 8

Dans de nombreuses applications, comme MsOffice (jusqu'à la version 2000 ou 2002), le nombre maximal de caractères par cellule était de 255. Le transfert de données de programmes capables de gérer plus de 255 caractères par champ vers / depuis ces applications était un cauchemar. Actuellement, la limite est de moins en moins gênante.

Answer 9

Une autre raison peut être que dans de très anciennes bibliothèques d'accès aux données sous Windows, telles que RDO et ADO (version COM non ADO.NET), vous deviez appeler une méthode spéciale, GetChunk, pour obtenir les données d'une colonne de plus de 255 caractères. . Si vous limitez une colonne varchar à 255, ce code supplémentaire n'est pas nécessaire.