¿Por qué históricamente la gente usa 255 no 256 para magnitudes de campo de base de datos?
A menudo se ven campos de base de datos configurados para tener una magnitud de 255 caracteres, ¿cuál es la razón tradicional / histórica de por qué? Supongo que tiene algo que ver con los límites de paginación / memoria, y el rendimiento, pero la distinción entre 255 y 256 siempre me ha confundido.
varchar(255)
Considerando que esto es una capacidad o magnitud, no es un indexador, ¿por qué se prefiere 255 sobre 256? Es un byte reservado para algún propósito (terminator o null o algo)?
Presumiblemente varchar (0) es una tontería (tiene capacidad cero)? En cuyo caso 2^8 de espacio debe ser 256 seguramente?
¿Hay otras magnitudes que proporcionen beneficios de rendimiento? Por ejemplo, ¿varchar(512) tiene menos rendimiento que varchar(511) o varchar(510)?
¿Es este valor el mismo para todas las bases de datos de relaciones, antiguas y nuevas?
Descargo de responsabilidad - Soy un desarrollador no un DBA, utilizo tamaños de campo y tipos que se adaptan a mi lógica de negocio donde se conoce, pero me gustaría saber histórico razón de esta preferencia, incluso si ya no es relevante (pero aún más si todavía es relevante).
Editar:
Gracias por las respuestas, parece haber cierto consenso de que un byte se usa para almacenar el tamaño, pero esto no resuelve el asunto definitivamente en mi mente.
Si los metadatos (longitud de cadena) se almacenan en la misma memoria/disco contiguo, tiene algún sentido. 1 byte de metadatos y 255 bytes de datos de cadena, se adaptarían muy bien, y caben en 256 bytes contiguos de almacenamiento, que presumiblemente es limpio y ordenado.
Pero...Si los metadatos (longitud de cadena) se almacenan por separado de los datos de cadena reales (en una tabla maestra tal vez), entonces restringir la longitud de los datos de cadena en un byte, solo porque es más fácil almacenar solo un entero de 1 byte de metadatos parece un poco extraño.
En ambos casos, parecería ser una sutileza que probablemente depende de la implementación de la base de datos. La práctica de usar 255 parece bastante generalizada, por lo que alguien en algún lugar debe haber argumentado un buen caso para ello en el principio, puede alguien recordar lo que ese caso era / es? Los programadores no adoptarán ninguna práctica nueva sin una razón, y esto debe haber sido nuevo una vez.
13 answers
Con una longitud máxima de 255 caracteres, el DBMS puede elegir usar un solo byte para indicar la longitud de los datos en el campo. Si el límite fuera 256 o mayor, se necesitarían dos bytes.
Un valor de longitud cero es ciertamente válido para los datos varchar (a menos que esté restringido de otra manera). La mayoría de los sistemas tratan una cadena vacía como distinta de NULL, pero algunos sistemas (notablemente Oracle) tratan una cadena vacía de forma idéntica a NULL. Para sistemas donde una cadena vacía no es NULL, un se necesitaría un bit adicional en algún lugar de la fila para indicar si el valor debe considerarse NULO o no.
Como usted nota, esta es una optimización histórica y probablemente no es relevante para la mayoría de los sistemas actuales.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-02-26 09:44:33
255 era el límite de varchar en mySQL4 y anteriores.
También 255 caracteres + terminador nulo = 256
O descriptor de longitud de 1 byte da un rango posible 0-255 caracteres
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-02-26 09:47:09
255 es el valor numérico más grande que se puede almacenar en un entero sin signo de un solo byte (suponiendo bytes de 8 bits)-por lo tanto, las aplicaciones que almacenan la longitud de una cadena para algún propósito preferirían 255 sobre 256 porque significa que solo tienen que asignar 1 byte para la variable "tamaño".
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-02-26 09:43:31
Del Manual de MySQL:
Tipo de datos:
VARCHAR(M), VARBINARY (M)Almacenamiento requerido:
L + 1 bytes si los valores de columna requieren 0 – 255 bytes, L + 2 bytes si los valores pueden requerir más de 255 bytes
Entender y tomar decisiones.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-03-27 15:30:33
255 es el valor máximo de un entero de 8 bits : 11111111 = 255.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-02-26 09:43:59
Creo que tiene que ver con programadores de la vieja escuela, ni siquiera puedo recordar por qué lo hicimos.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-02-26 09:45:51
Una longitud máxima de 255 permite al motor de base de datos usar solo 1 byte para almacenar la longitud de cada campo. Está en lo correcto que 1 byte de espacio le permite almacenar 2^8 = 256 valores distintos para la longitud de la cadena.
Pero si permite que el campo almacene cadenas de texto de longitud cero, debe poder almacenar cero en la longitud. Por lo tanto, puede permitir 256 valores de longitud distintos, comenzando en cero: 0-255.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-02-26 10:11:42
A menudo los varchars se implementan como cadenas pascal: manteniendo la longitud real en el byte #0. Por lo tanto, la longitud estaba limitada a 255. (El valor de un byte varía de 0 a 255.)
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-02-26 09:45:36
Recordó los fundamentos del almacenamiento de bits/bytes, requiere un byte para almacenar enteros por debajo de 256 y dos bytes para cualquier entero entre 256 y 65536. Por lo tanto, requiere el mismo espacio (dos bytes) para almacenar 511 o 512 o para el caso 65535.... Por lo tanto, está claro que este argumento mencionado en la discusión anterior es N/A para varchar(512) o varchar(511).
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-07-03 09:09:42
8 bits sin signo = 256 bytes
255 caracteres + byte 0 para longitud
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-02-26 09:53:06
Solía ser que todas las cadenas requerían un terminador NUL, o "barra invertida-cero". Las bases de datos actualizadas no tienen eso. Era "255 caracteres de texto" con un "\0 " agregado automáticamente al final para que el sistema supiera dónde terminaba la cadena. Si dijeras VARCHAR(256), terminaría siendo 257 y luego estarías en el siguiente registro para un personaje. Derrochador. Por eso todo era VARCHAR(255) y VARCHAR(31). Por costumbre, el 255 parece haberse quedado pero el 31 se convirtió en el 32 y el La 511 se convirtió en la 512. Es difícil hacerme escribir VARCHAR (256).
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-07-16 19:37:01
Creo que esto podría responder a su pregunta. Parece que era el límite máximo de varchar en sistemas anteriores. Lo tomé de otra pregunta de Stackoverflow.
Es difícil saber cuál es la dirección postal más larga, por supuesto, por lo que muchas personas eligen un VARCHAR largo que es ciertamente más largo que cualquier dirección. Y 255 es habitual porque puede haber sido la longitud máxima de un VARCHAR en algunas bases de datos en los albores del tiempo (así como PostgreSQL hasta más recientemente).
¿Hay desventajas al usar un varchar genérico (255) para todos los campos basados en texto?
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-23 12:18:13
Los datos se guardan en la memoria en el sistema binario y 0 y 1 son dígitos binarios. El número binario más grande que puede caber en 1 byte (8 bits) es 11111111 que convierte al decimal 255.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-09-26 19:49:22