Почему исторически люди используют 255, а не 256 для значений полей базы данных?
вы часто видите, что поля базы данных имеют величину 255 символов, какова традиционная / историческая причина почему? Я предполагаю, что это связано с ограничениями подкачки / памяти и производительностью, но различие между 255 и 256 всегда меня смущало.
varchar(255)
учитывая, что это емкость или величины, не индексатор, почему 255 предпочтительнее 256? является байтом, зарезервированным для какой-либо цели (terminator или null или что-то)?
предположительно varchar (0) является нонсенсом (имеет нулевую емкость)? В этом случае 2^8 пространства должно быть 256, конечно?
существуют другие величины, которые обеспечивают преимущества в производительности? Например, varchar(512) менее эффективен, чем varchar(511) или varchar (510)?
это значение одинаково для всех баз данных отношений, старых и новых?
отказ от ответственности - Я разработчик не DBA, я использую размеры полей и типы, которые подходят для моего бизнеса логика, где это известно, но я хотел бы знать исторического причина этого предпочтения, даже если оно больше не актуально (но даже больше, если оно все еще актуально).
Edit:
Спасибо за ответы, кажется, есть некоторое согласие, что байт используется для хранения размера, но это не решает вопрос окончательно в моем уме.
если метаданные (длина строки) хранятся в одной и той же непрерывной памяти/диске, это имеет смысл. 1 байт метаданные и 255 байт строковых данных очень хорошо подходят друг другу и вписываются в 256 смежных байтов хранения, что, по-видимому, аккуратно и аккуратно.
но...Если метаданные (длина строки) хранятся отдельно от фактических строковых данных (возможно, в главной таблице), то ограничить длину строковых данных одним байтом, просто потому, что проще хранить только 1 байтовое целое число метаданных, кажется немного странным.
в обоих случаях, казалось бы, тонкость что, вероятно, зависит от реализации БД. Практика использования 255 кажется довольно распространенной, поэтому кто-то где-то должен был аргументировать хороший случай для этого в начале, может ли кто-нибудь вспомнить, что это был/есть? Программисты не принимают никаких новых практик без причины, и это, должно быть, было когда-то новым.
13 ответов
С максимальной длиной 255 символов СУБД может использовать один байт для указания длины данных в поле. Если ограничение 256 или больше, потребуется два байта.
значение длины ноль, безусловно, допустимо для varchar data (если не ограничено иначе). Большинство систем рассматривают такую пустую строку как отличную от NULL, но некоторые системы (особенно Oracle) обрабатывают пустую строку идентично NULL. Для систем, где пустая строка не является NULL, дополнительный бит где-то в строке потребуется, чтобы указать, следует ли считать значение NULL или нет.
Как вы заметили, это историческая оптимизация и, вероятно, не относится к большинству систем сегодня.
255 был ограничение varchar в mySQL4 и ранее.
также 255 символов + нулевой Терминатор = 256
или дескриптор длины 1 байта дает возможный диапазон 0-255 символов
255-это наибольшее числовое значение, которое может быть сохранено в однобайтовом целочисленном без знака (предполагая 8-битные байты)-следовательно, приложения, которые хранят длину строки для какой - либо цели, предпочли бы 255 над 256, потому что это означает, что им нужно только выделить 1 байт для переменной "size".
Из Руководства MySQL:
Тип Данных :
VARCHAR(M), VARBINARY (M)Требуются Хранения:
L + 1 байт, если значения столбцов требуют 0-255 байт, L + 2 байта, если значения могут потребовать более 255 байт
разобраться и сделать выбор.
максимальная длина 255 позволяет Database engine использовать только 1 байт для хранения длины каждого поля. Вы правы в том, что 1 байт пространства позволяет хранить 2^8=256 различных значений для длины строки.
но если вы разрешаете полю хранить текстовые строки нулевой длины, вы должны иметь возможность хранить ноль в длине. Таким образом, вы можете разрешить 256 различных значений длины, начиная с нуля: 0-255.
часто varchars реализованы как строки pascal: удерживая фактическую длину в байте #0. Поэтому длина была привязана к 255. (Значение байта варьируется от 0 до 255.)
вспомнил основы хранения битов / байтов, требуется один байт для хранения целых чисел ниже 256 и два байта для любого целого числа между 256 и 65536. Следовательно, для хранения 511 или 512 или 65535 требуется одно и то же пространство (два байта).... Таким образом, ясно, что этот аргумент, упомянутый в обсуждении выше, является N/A для varchar(512) или varchar(511).
раньше для всех строк требовался нуль-Терминатор или"обратная косая черта-ноль". Обновленные базы данных не имеют этого. Это было "255 символов текста" с "\0", добавленным автоматически в конце, чтобы система знала, где заканчивается строка. Если вы сказали VARCHAR (256), это будет 257, а затем вы будете в следующем регистре для одного символа. Расточительный. Вот почему все было VARCHAR (255) и VARCHAR(31). По привычке 255, кажется, застрял вокруг, но 31 стал 32-х и 511 превратились в 512. Это странно. Трудно заставить себя написать VARCHAR (256).
Я думаю, что это может ответить на ваш вопрос. Похоже, это был максимальный предел varchar в более ранних системах. Я снял его с другого вопроса stackoverflow.
трудно узнать, какой самый длинный почтовый адрес, конечно, поэтому многие люди выбирают длинный VARCHAR, который, безусловно, длиннее любого адреса. И 255 обычно, потому что это может быть максимальная длина VARCHAR в некоторых базах данных на заре времени (а также PostgreSQL до более недавно.)
есть ли недостатки в использовании универсального типа varchar(255) для всех текстовых полей?
данные сохраняются в памяти в двоичной системе, а 0 и 1-двоичные цифры. Наибольшее двоичное число, которое может поместиться в 1 байт (8 бит), - 11111111, которое преобразуется в десятичное 255.