Почему исторически люди используют 255, а не 256 для величин полей базы данных?

190

Вы часто видите, что поля базы данных имеют величину 255 символов. В чем заключается традиционная / историческая причина? Я предполагаю, что это как-то связано с ограничениями подкачки / памяти и производительностью, но различие между 255 и 256 меня всегда смущало.

varchar(255)

Учитывая, что это емкость или величина, а не индексатор , почему 255 предпочтительнее 256? Байт зарезервирован для какой-либо цели (терминатор или ноль или что-то)?

Предположительно varchar (0) это ерунда (имеет нулевую емкость)? В каком случае 2 ^ 8 места должно быть 256 обязательно?

Существуют ли другие величины, которые обеспечивают выигрыш в производительности? Например, varchar (512) менее эффективен, чем varchar (511) или varchar (510)?

Является ли это значение одинаковым для всех баз данных отношений, старых и новых?

Отказ от ответственности - я разработчик, а не администратор баз данных, я использую размеры и типы полей, которые соответствуют моей бизнес-логике, где это известно, но я хотел бы знать историческую причину этого предпочтения, даже если оно больше не актуально (но даже больше, если это все еще актуально).

Редактировать:

Спасибо за ответы, кажется, есть некоторое понимание того, что байт используется для хранения размера, но это не решает вопрос окончательно в моем уме.

Если метаданные (длина строки) хранятся в одной и той же смежной памяти / диске, это имеет некоторый смысл. 1 байт метаданных и 255 байт строковых данных очень хорошо подходили бы друг другу и помещались в 256 смежных байтов памяти, что, по-видимому, аккуратно и аккуратно.

Но ... Если метаданные (длина строки) хранятся отдельно от фактических строковых данных (возможно, в основной таблице), то ограничить длину строковых данных одним байтом только потому, что проще хранить только 1-байтовое целое число метаданных кажется немного странным.

В обоих случаях это может показаться тонкостью, которая, вероятно, зависит от реализации БД. Практика использования 255 кажется довольно распространенной, поэтому кто-то где-то, должно быть, вначале аргументировал это хорошим аргументом, может кто-нибудь вспомнить, что это был за случай? Программисты не примут никакой новой практики без причины, и это, должно быть, когда-то было новым.

Андрей М
источник
3
Потому что количество символов начинается с 0 до N-1. Таким образом, 256 символов будут объявлены как varchar (255). Если я не ошибаюсь.
Бухаке Синди
3
Может быть, потому что айтишники начинают считать с 0, а не с 1;)?
Ромен Линсолас
Я думаю, что это связано с программистами старой школы, даже не помню, почему мы это сделали.
Сердитый
7
@ Elite Gentleman: нет, число в скобках - это истинная длина ... Как и в объявлениях массива C: x [256] дает x [0] ... x [255].
RedPandaCurios
@romaintaz - но рассмотрим массив, который может хранить 1 элемент. Вы объявляете это чем-то [1] и получаете к нему доступ чем-то [0]. Вопрос в том, почему в SQL мы объявляем емкость на 1 байт меньше, чем кажется на первый взгляд логичным.
Андрей М

Ответы:

167

При максимальной длине 255 символов СУБД может выбрать использование одного байта для указания длины данных в поле. Если бы предел был 256 или больше, понадобилось бы два байта.

Значение нулевой длины, безусловно, допустимо для varcharданных (если не оговорено иное). Большинство систем рассматривают такую ​​пустую строку как отличную от NULL, но некоторые системы (особенно Oracle) обрабатывают пустую строку идентично NULL. Для систем, где пустая строка не равна NULL, потребуется дополнительный бит где-то в строке, чтобы указать, следует ли считать значение NULL или нет.

Как вы заметили, это историческая оптимизация и, вероятно, не относится к большинству систем сегодня.

Грег Хьюгилл
источник
Резервирование байта для длины имеет смысл, но WRT - ваш второй параграф, предположительно, / value / с нулевой длиной действителен, но допустим ли /acity / с нулевой длиной?
Эндрю М
1
@Andrew: я только что попробовал и PostgreSQL отвергает varchar(0). Вероятно, это не очень полезно, потому что значение может состоять только из двух вещей: пустой строки или NULL, и поэтому вы можете просто использовать bitдля этого.
Грег Хьюгилл
Поэтому верно предположить, что метаданные емкости хранятся в том же непрерывном блоке, что и сами данные, и, следовательно, для БД есть преимущество в том, чтобы хранить общее количество этих двух вещей (данных и метаданных) на одной странице (предположительно, 256). байт)?
Андрей М
@Andrew: Это предположение может быть или не быть верным в зависимости от деталей реализации рассматриваемой СУБД. Размер страницы обычно намного больше 256 байт. Как я уже упоминал, такая оптимизация иногда важна (например, если вы храните миллиарды небольших строк), но в большинстве случаев не стоит беспокоиться.
Грег Хьюгилл
3
Важность дискового пространства (и индексного пространства) не в том, что 256 может поместиться на странице, а в том, что 1 байт против 2 байт (для строк миллионы / миллиарды / триллионы) имеет большое значение.
ypercubeᵀᴹ
35

255 был пределом varchar в mySQL4 и более ранних версиях.

Также 255 символов + нулевой терминатор = 256

Или 1-байтовый дескриптор дает возможный диапазон 0-255 символов

RedPandaCurios
источник
И чтение в char foo[256]это важно, потому что управлению памятью нравятся степени 2. см .: stackoverflow.com/questions/3190146/… Выделение char foo[257]будет либо фрагментировать память, либо занимать 512 байт.
ebyrob
4
Разве varchar не хранит длину строки и, следовательно, не нуждается в нулевом терминаторе?
Cruncher
19

255 - это наибольшее числовое значение, которое может быть сохранено в однобайтовом целом числе без знака (при условии 8-битных байтов) - следовательно, приложения, которые для какой-то цели хранят длину строки, предпочтут 255 вместо 256, поскольку это означает, что они должны только выделить 1 байт для переменной размера.

янтарный
источник
17

Из руководства MySQL:

Тип данных:
VARCHAR (M), VARBINARY (M)

Требуется память:
L + 1 байт, если значения столбца требуют 0 - 255 байт, L + 2 байта, если значения могут требовать более 255 байт

Понять и сделать выбор.

Анил Шинде
источник
Да, но M represents the declared column length in characters for nonbinary string types and bytes for binary string types. L represents the actual length in bytes of a given string value. dev.mysql.com/doc/refman/5.7/en/storage-requirements.html
DLight
13

255 - максимальное значение 8-битного целого числа: 11111111 = 255.

реми бургарел
источник
7

Максимальная длина 255 позволяет ядру базы данных использовать только 1 байт для хранения длины каждого поля. Вы правы, что 1 байт пространства позволяет хранить 2 ^ 8 = 256 различных значений для длины строки.

Но если вы разрешите полю хранить текстовые строки нулевой длины, вы должны иметь возможность хранить ноль в длину. Таким образом, вы можете разрешить 256 различных значений длины, начиная с нуля: 0-255.

MarkJ
источник
6

Часто varchars реализуются в виде строк паскаля: содержат фактическую длину в байте # 0. Следовательно, длина была ограничена 255. (Значение байта варьируется от 0 до 255.)

Влад
источник
5

<<

Вспомнил основы хранения битов / байтов, требуется один байт для хранения целых чисел ниже 256 и два байта для любого целого числа от 256 до 65536. Следовательно, для хранения 511 или 512 или, если уж на то пошло, 65535 требуется одинаковое пространство (два байта) .... Таким образом, ясно, что аргумент this, упомянутый в приведенном выше обсуждении, отсутствует для varchar (512) или varchar (511).

Баладжи Катика
источник
4

8 бит без знака = 256 байт

255 символов + байт 0 для длины

ГБН
источник
3

Раньше для всех строк требовался терминатор NUL или «обратный слеш-ноль». Обновленные базы данных не имеют этого. Это было «255 символов текста» с добавлением «\ 0» в конце, чтобы система знала, где заканчивается строка. Если бы вы сказали VARCHAR (256), в итоге получилось бы 257, и тогда вы оказались бы в следующем регистре для одного символа. Расточительное. Вот почему все было VARCHAR (255) и VARCHAR (31). По привычке 255, кажется, застряли, но 31-й стал 32-м, а 511-й стал 512-м. Эта часть странная. Трудно заставить себя написать VARCHAR (256).

Greg
источник
0

Я думаю, что это может ответить на ваш вопрос. Похоже, это был максимальный предел varchar в более ранних системах. Я снял это с другого вопроса stackoverflow.

Конечно, трудно понять, какой самый длинный почтовый адрес, поэтому многие люди выбирают длинный VARCHAR, который, безусловно, длиннее любого адреса. И 255 является обычным, потому что это могло быть максимальной длиной VARCHAR в некоторых базах данных на заре времени (как и в PostgreSQL до недавнего времени).

Есть ли недостатки в использовании общего varchar (255) для всех текстовых полей?

Нео М Хакер
источник
0

Данные сохраняются в памяти в двоичной системе, а 0 и 1 - двоичные цифры. Наибольшее двоичное число, которое может вписаться в 1 байт (8 бит), равно 11111111, которое преобразуется в десятичное 255.

Ejaz
источник