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

158

Dans plusieurs cours, livres et emplois, j'ai vu des champs de texte définis comme VARCHAR (255) comme une sorte de texte par défaut pour le texte "court". Y a-t-il une bonne raison pour laquelle une longueur de 255 est choisie si souvent, autre que d'être un joli nombre rond ? S'agit-il d'un retard d'un certain temps dans le passé où il y avait une bonne raison (que cela s'applique ou non aujourd'hui)?

Je me rends compte, bien sûr, qu'une limite plus serrée 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, seulement qu'il s'agit d'une chaîne "courte".

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, car vous ne sauveriez que deux octets par rapport à VARCHAR (256), et vous pourriez tout aussi facilement enregistrer deux autres octets en le déclarant VARCHAR (253).

database database-design types varchar Kip
la source

Réponses:

109

Historiquement, 255 caractères ont souvent été la longueur maximale d'un VARCHARdans certains SGBD, et cela finit parfois par être le maximum effectif si vous souhaitez utiliser UTF-8 et indexer la colonne (en raison des limitations de longueur d'index).

le chaos
la source
4
@CharlesBretana: si vous lisez le reste de la phrase que vous avez citée, vous trouverez l'explication exacte que vous demandez.
chaos
2
@CharlesBretana: Par "faux UTF-8", j'entends le codage "utf8" de MySQL, qui, comme je l'ai mentionné, réserve (et est limité à) 3 octets par caractère. Ce n'est pas une très bonne version de UTF-8; si vous voulez un UTF-8 décent dans MySQL, vous devez utiliser son encodage "utf8mb4". Mais les gens sont beaucoup plus susceptibles de ne pas le savoir et d'aller avec "utf8", et beaucoup plus susceptibles de vouloir UTF-8 que tout autre encodage, donc, hop, ils se retrouvent avec une longueur indexable maximale de 255 caractères dans un VARCHAR. Nonobstant votre stupéfaction.
chaos
3
@CharlesBretana: Je l'ai maintenant expliqué trois fois et pas une seule chose n'a changé. La limite de longueur d'index de MySQL est toujours de 767 octets, le nombre d'octets nécessaires pour encoder un caractère UTF-8 de 3 octets est toujours de 3 et le plancher (767/3) est toujours de 255. Votre détermination à trouver quelque chose à confondre avec la croyance des mendiants .
chaos
1
@CharlesBretana (Désolé d'être en retard à toute cette fête) Je ne suis pas un spécialiste de la base de données, mais je pense que ce que le chaos dit est: oui, une colonne `` Fake UTF-8 '' peut contenir plus de 255 caractères, mais l'index sera ne fonctionne que sur les 255 premiers caractères du varchar, ce qui en fait effectivement le maximum d'une colonne si vous voulez qu'il soit entièrement indexé. Maintenant c'est seulement ce que j'ai compris de ses explications, je me trompe peut-être, je ne suis pas du tout un expert des index SQL.
Francis Lord
2
@CharlesBretana Si vous regardez correctement la réponse de Chaos, vous remarquerez qu'elle se divise en 2 parties: 1. La raison historique derrière Varchar (255) étant si courante (c'était le maximum sur certains SGBD plus anciens), 2. Même aujourd'hui, c'est encore une limitation pour certains en raison des limitations d'index évoquées précédemment, les parties 1 et 2 ne sont pas liées. La partie 1 est la réponse réelle à la question, la partie 2 est une note d'accompagnement qui est toujours pertinente pour la question car elle explique pourquoi même aujourd'hui cela peut encore être une limitation. (SUITE ->)
Francis Lord
161

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

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

Robert Harvey
la source
90
J'aime cette phrase: "nécessitant frivole un autre octet entier". =)
MusiGenesis
7
Cela est-il vrai pour les bases de données où les varchars sont UTF-8?
antak
1
@antak: Dans MySQL, en utilisant InnoDB, toute colonne de clé ne peut pas dépasser 767 octets. Si une colonne VARCHAR est UTF8 (ce qui signifie que chaque caractère peut prendre jusqu'à 3 octets), la longueur maximale autorisée de la colonne est floor (767/3) = 255. Je suppose que "767" a été choisi exactement pour cette raison.
BlueRaja - Danny Pflughoeft
1
Si le jeu de caractères estutf8 , varchar(85)est la limite sur laquelle le croisement fait basculer l' octet de longueur de un à deux octets. Si c'est utf8mb4, c'est varchar(63). Celles-ci sont importantes car elles représentent le maximum auquel la longueur d' un VARCHAR peut être étendue grâce à l'utilisation d'ALTER TABLE en ligne . Par conséquent, j'ai dérivé ces nombres en créant un tableau avec une varchar(2) charset utf8colonne et en voyant jusqu'où je pouvais l'étendre ALGORITHM=INPLACE.
antak
Cela a encore plus de sens si l'on considère que de nombreuses «bases de données» Back In The Day étaient stockées sur bande magnétique. Il était très courant de lire des données dans des «blocs» qui étaient dimensionnés par multiples de deux. De cette façon, les données étaient stockées le plus efficacement (et lorsque vous fonctionniez sur un ancien mainframe, de petites économies comme celles-ci étaient des optimisations décisives).
TMN
23

Probablement parce que SQL Server et Sybase (pour n'en nommer que deux que je connais bien) avaient un maximum de 255 caractères dans le nombre de caractères dans une VARCHARcolonne. Pour SQL Server, cela a changé dans la version 7 en 1996/1997 environ ... mais les vieilles habitudes meurent parfois dur.

Charles Bretana
la source
8
+1 pour citer des bases de données et des versions spécifiques. Et "les vieilles habitudes meurent dur" est probablement la réponse la plus vraie de toutes.
Andrew M
17

Je vais répondre à la question littérale: non , il n'y a pas une bonne raison pour laquelle vous voyez VARCHAR (255) utilisé si souvent (il y a en effet des raisons , comme discuté dans les autres réponses, mais pas de 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 serait une question d'insignifiance quasi totale même si vous parliez de CHAR au lieu de VARCHAR.

MusiGenesis
la source
1 octet sur 255 équivaut à 0,4%. Parfois, vous vous souciez du dernier demi-pour cent environ. Parfois non. Si vos coûts d'hébergement et de performance s'élèvent à des dizaines de dollars, vous ne vous souciez probablement pas. S'ils atteignent des millions, ils le font probablement.
Edward Brey
2
@EdwardBrey: si la loi de Moore est toujours vraie, ma réponse ici est 16 fois plus valable qu'elle ne l'était quand je l'ai écrite.
MusiGenesis
À moins que nous ayons découvert 16 fois plus de façons dont les ordinateurs peuvent nous aider. La vitesse est toujours une caractéristique.
Edward Brey
14

Quand vous dites que 2^8vous obtenez 256, mais les nombres en termes informatiques commencent à partir du nombre 0. Donc, alors vous avez le 255, vous pouvez le sonder dans un masque Internet pour l'IP ou dans l'IP elle-même.

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

Est ce que ça aide?

exec.-
la source
1
Avec les entiers, vous comptez à partir de 0 et vous terminez à 255. Mais avec des places dans une chaîne, vous comptez à partir de la 1ère place, donc cela n'a pas de sens de terminer à la 256ème place, car vous avez commencé à 1 au lieu de 0? Je ne suis pas encore entièrement d'accord avec varchar (256), à cause des résultats de string_length (), mais je ne suis vraiment pas certain.
HoldOffHunger
1
Les chaînes @HoldOffHunger dans une base de données peuvent avoir une longueur de zéro caractère, donc la plage de longueurs autorisée lorsque la longueur est stockée sur huit bits est comprise entre 0 et 255. Si vous vouliez dire que toutes les chaînes doivent avoir au moins un caractère, vous pourrait prendre en charge des chaînes de 256 caractères avec une longueur de huit bits.
phoog le
7

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, car vous ne sauveriez que deux octets par rapport à VARCHAR (256), et vous pourriez tout aussi facilement enregistrer deux autres octets en le déclarant VARCHAR (253).

Non, vous n'économisez 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 terminé. 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.

Stefano Borini
la source
3
Cette affirmation n'est pas vraie pour toutes les bases de données. de nombreuses bases de données utilisent des champs varchar de la taille donnée dans les tables afin de ne pas avoir à déplacer des lignes lorsque ce champ est modifié pour une ligne.
SingleNegationElimination
Oui, tu as raison. cela dépend de la mise en œuvre. Vous devez consulter le manuel du vendeur pour voir ce qui est le cas
Stefano Borini
2
Cela peut être permis, mais l'implémentation de VARCHARcette façon va à l'encontre de l' intérêt d'utiliser VARCHARau lieu de CHAR.
dan04
4

Un nombre de 1 octet non signé peut contenir la plage [0-255] incluse. Donc, quand vous voyez 255, c'est surtout parce que les programmeurs pensent en base10 (obtenez la blague?) :)

En fait, pendant un certain temps, 255 était la plus grande taille que vous pouviez donner à un VARCHAR dans MySQL, et il y a des avantages à utiliser VARCHAR sur TEXT avec l'indexation et d'autres problèmes.

gahooa
la source
4

Dans de nombreuses applications, comme MsOffice (jusqu'à la version 2000 ou 2002), le nombre maximum de caractères par cellule était de 255. Déplacer des données depuis des 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.

Joaquin Montes
la source
2

0000 0000 -> c'est un nombre binaire de 8 bits. Un chiffre représente un peu.

Vous comptez comme ça:

0000 0000 → (0)

0000 0001 → (1)

0000 0010 → (2)

0000 0011 → (3)

Chaque bit peut être l'une des deux valeurs suivantes: activé ou désactivé. Le nombre total le plus élevé peut être représenté par multiplication:

2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 - 1 = 255

Ou 

2^8 - 1.

Nous soustrayons un car le premier nombre est 0.

255 peut contenir un peu (sans jeu de mots) de valeurs.

Au fur et à mesure que nous utilisons plus de bits, la valeur maximale augmente de manière exponentielle. Par conséquent, à de nombreuses fins, ajouter plus de bits est excessif.

ScottyBlades
la source
1

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

Garçon Booji
la source