¿Hay una buena razón por la que veo que VARCHAR (255) se usa con tanta frecuencia (en lugar de otra longitud)?


158

En varios cursos, libros y trabajos, he visto campos de texto definidos como VARCHAR (255) como el tipo predeterminado para el texto "corto". ¿Hay alguna buena razón para elegir una longitud de 255 con tanta frecuencia, aparte de ser un buen número redondo ? ¿Es un retraso de algún tiempo en el pasado cuando había una buena razón (si se aplica hoy o no)?

Me doy cuenta, por supuesto, que un límite más estricto sería más ideal, si de alguna manera conoces la longitud máxima de la cuerda. Pero si está utilizando VARCHAR (255), eso probablemente indica que no conoce la longitud máxima, solo que es una cadena "corta".


Nota: Encontré esta pregunta ( varchar (255) v tinyblob v tinytext ), que dice que VARCHAR ( n ) requiere n +1 bytes de almacenamiento para n <= 255, n +2 bytes de almacenamiento para n > 255. ¿Es esta la única razón? Eso parece algo arbitrario, ya que solo estaría ahorrando dos bytes en comparación con VARCHAR (256), y podría guardar fácilmente otros dos bytes declarándolo VARCHAR (253).

Respuestas:


109

Históricamente, 255 caracteres a menudo han sido la longitud máxima de a VARCHARen algunos DBMS, y a veces sigue siendo el máximo efectivo si desea usar UTF-8 y tener la columna indexada (debido a las limitaciones de longitud del índice).


44
@CharlesBretana: si lee el resto de la oración que citó, encontrará la explicación exacta que está solicitando.
caos

2
@CharlesBretana: Por "UTF-8 falso" me refiero a la codificación "utf8" de MySQL, que como mencioné reserva (y está limitada a) 3 bytes por carácter. Esta no es una muy buena versión de UTF-8; si desea UTF-8 decente en MySQL, debe usar su codificación "utf8mb4". Pero es mucho más probable que las personas no lo sepan y utilicen "utf8", y es mucho más probable que quieran UTF-8 que cualquier otra codificación, por lo que, presto, terminan con una longitud indexable máxima de 255 caracteres en un VARCHAR. A pesar de su asombro.
caos

3
@CharlesBretana: ahora lo he explicado tres veces y no ha cambiado nada. El límite de longitud del índice de MySQL sigue siendo de 767 bytes, el número de bytes necesarios para codificar un carácter UTF-8 de 3 bytes sigue siendo 3, y el piso (767/3) sigue siendo 255. Su determinación de encontrar algo que confundir sobre la creencia de los mendigos .
caos

1
@CharlesBretana (Perdón por llegar tarde a toda esta fiesta) No soy especialista en DB, pero creo que lo que dice el caos es: sí, una columna 'Fake UTF-8' puede tener más de 255 caracteres, pero el índice sí solo funciona en los primeros 255 caracteres del varchar, por lo que es efectivamente el máximo de una columna si desea que esté completamente indexada. Ahora eso es solo lo que entendí de sus explicaciones, puedo estar equivocado, no soy un experto en índices SQL en absoluto.
Francis Lord

2
@CharlesBretana Si observa correctamente la respuesta de Chaos, notará que se separó en 2 partes: 1. La razón histórica detrás de Varchar (255) es tan común (solía ser el máximo en algunos DBMS anteriores), 2. Incluso hoy en día, sigue siendo una limitación para algunos debido a las limitaciones del índice discutidas anteriormente, las partes 1 y 2 no están vinculadas. La parte 1 es la respuesta real a la pregunta, la parte 2 es una nota al margen que sigue siendo relevante para la pregunta porque explica por qué aún hoy puede ser una limitación. (CONTINUACIÓN ->)
Francis Lord

161

255 se utiliza porque es el mayor número de caracteres que se pueden contar con un número de 8 bits. Maximiza el uso del recuento de 8 bits, sin requerir frívolamente otro byte completo para contar los caracteres superiores a 255.

Cuando se usa de esta manera, VarChar solo usa el número de bytes + 1 para almacenar su texto, por lo que podría configurarlo en 255, a menos que desee un límite estricto (como 50) en el número de caracteres en el campo.


90
Me gusta esa frase: "frívolamente requiere otro byte completo". =)
MusiGenesis

77
¿Es esto cierto para las bases de datos donde los varchars son UTF-8?
antak

1
@antak: en MySQL, usando InnoDB, cualquier columna de clave no puede tener más de 767 bytes. Si una columna VARCHAR es UTF8 (lo que significa que cada carácter puede tomar hasta 3 bytes), la longitud máxima permitida de la columna es floor (767/3) = 255. Supongo que se eligió "767" exactamente por esa razón.
BlueRaja - Danny Pflughoeft

1
Si el juego de caracteres esutf8 , varchar(85)es el límite sobre el cual el cruce inclina el byte de longitud de uno a dos bytes. Si es utf8mb4, es varchar(63). Estos son significativos porque son el máximo al que se puede extender la longitud de un VARCHAR mediante el uso de la TABLA DE ALTERACIÓN en línea . En consecuencia, deduje esos números creando una tabla con una varchar(2) charset utf8columna y viendo hasta qué punto pude extenderlo dado ALGORITHM=INPLACE.
antak

Tiene aún más sentido cuando se considera que muchas "bases de datos" Back In The Day estaban almacenadas en una cinta magnética. Era muy común leer datos en "bloques" que se dimensionaron en múltiplos de dos. De esta manera, los datos se almacenaban de manera más eficiente (y cuando se ejecutaba en un mainframe antiguo, las pequeñas eficiencias como esa eran optimizaciones de fabricación automática).
TMN

23

Probablemente porque SQL Server y Sybase (por nombrar dos con los que estoy familiarizado) solían tener un máximo de 255 caracteres en la cantidad de caracteres en una VARCHARcolumna. Para SQL Server, esto cambió en la versión 7 en 1996/1997 más o menos ... pero los viejos hábitos a veces mueren con dificultad.


8
+1 para citar DB y versiones específicas. Y "Los viejos hábitos mueren duro" es probablemente la respuesta más verdadera de todas.
Andrew M

17

Voy a responder la pregunta literal: no , no hay una buena razón por la que veas que VARCHAR (255) se usa con tanta frecuencia (de hecho , hay razones , como se discutió en las otras respuestas, simplemente no son buenas). No encontrará muchos ejemplos de proyectos que hayan fallado catastróficamente porque el arquitecto eligió VARCHAR (300) en lugar de VARCHAR (255). Este sería un problema de insignificancia casi total, incluso si estuviera hablando de CHAR en lugar de VARCHAR.


1 byte de 255 es 0.4%. A veces te importa el último medio por ciento más o menos. A veces no lo haces. Si sus costos de alojamiento y rendimiento llegan a las decenas de dólares, probablemente no le importe. Si se encuentran con millones, probablemente lo hagan.
Edward Brey

2
@EdwardBrey: si la Ley de Moore sigue siendo cierta, mi respuesta aquí es 16 veces más válida de lo que era cuando la escribí.
MusiGenesis

A menos que hayamos descubierto 16 veces más formas en que las computadoras pueden ayudarnos. La velocidad sigue siendo una característica.
Edward Brey

14

Cuando dices 2^8que obtienes 256, pero los números en términos de computadoras comienzan desde el número 0. Entonces, tienes el 255, puedes probarlo en una máscara de Internet para la IP o en la propia IP.

255 es el valor máximo de un entero de 8 bits: 11111111 = 255

¿Eso ayuda?


1
Con los enteros, cuentas a partir de 0 y terminas en 255. Pero con los lugares en una cadena, cuentas a partir del 1er lugar, así que no tiene sentido terminar en el lugar 256, porque comenzaste en 1 en lugar de 0? Todavía no estoy de acuerdo con varchar (256) por completo debido a los resultados de string_length (), pero realmente no estoy seguro.
HoldOffHunger

1
Las cadenas @HoldOffHunger en una base de datos pueden tener una longitud de cero caracteres, por lo que el rango permitido de longitudes cuando la longitud se almacena en ocho bits está entre 0 y 255. Si desea decir que las cadenas deben tener al menos un carácter, entonces podría admitir cadenas de 256 caracteres con una longitud de ocho bits.
phoog

7

Nota: Encontré esta pregunta ( varchar (255) v tinyblob v tinytext ), que dice que VARCHAR ( n ) requiere n +1 bytes de almacenamiento para n <= 255, n +2 bytes de almacenamiento para n > 255. ¿Es esta la única razón? Eso parece algo arbitrario, ya que solo estaría ahorrando dos bytes en comparación con VARCHAR (256), y podría guardar fácilmente otros dos bytes declarándolo VARCHAR (253).

No. no guarda dos bytes declarando 253. La implementación de varchar es muy probablemente un contador de longitud y una matriz de longitud variable y no terminada. Esto significa que si almacena "hola" en un varchar (255) ocupará 6 bytes: un byte para la longitud (el número 5) y 5 bytes para las cinco letras.


3
Esta afirmación no es cierta para todas las bases de datos. muchas bases de datos usan campos varchar del tamaño dado en las tablas para que no tengan que mover filas cuando ese campo se cambia por una fila.
SingleNegationElimination

Sí, tiene usted razón. su implementación depende. Debe consultar el manual del proveedor para ver cuál es el caso
Stefano Borini

2
Puede ser permisible, pero la implementación de VARCHAResa manera anula el punto de usar en VARCHARlugar de CHAR.
dan04

4

Un número de 1 byte sin signo puede contener el rango [0-255] inclusive. Entonces, cuando ves 255, es principalmente porque los programadores piensan en la base 10(¿entiendes el chiste?) :)

En realidad, por un tiempo, 255 fue el tamaño más grande que podría darle a un VARCHAR en MySQL, y hay ventajas al usar VARCHAR sobre TEXT con indexación y otros problemas.


4

En muchas aplicaciones, como MsOffice (hasta la versión 2000 o 2002), el número máximo de caracteres por celda era 255. Mover datos de programas capaces de manejar más de 255 caracteres por campo hacia / desde esas aplicaciones fue una pesadilla. Actualmente, el límite es cada vez menos difícil.


2

0000 0000 -> este es un número binario de 8 bits. Un dígito representa un bit.

Usted cuenta así:

0000 0000 → (0)

0000 0001 → (1)

0000 0010 → (2)

0000 0011 → (3)

Cada bit puede ser uno de dos valores: activado o desactivado. El número total más alto se puede representar por multiplicación:

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

O

2^8 - 1. 

Restamos uno porque el primer número es 0.

255 puede contener bastante (sin juego de palabras) de valores.

A medida que usamos más bits, el valor máximo aumenta exponencialmente. Por lo tanto, para muchos propósitos, agregar más bits es excesivo.


1

Otra razón puede ser que en bibliotecas de acceso a datos muy antiguas en Windows como RDO y ADO (versión COM no ADO.NET) tenía que llamar a un método especial, GetChunk, para obtener datos de una columna con más de 255 caracteres. Si limitó una columna varchar a 255, este código adicional no era necesario.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.