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