Есть ли веская причина, по которой я вижу, что VARCHAR(255) используется так часто (в отличие от другой длины)?
-
10-07-2019 - |
Вопрос
Во многих курсах, книгах и работах я видел текстовые поля, определенные как VARCHAR(255), как стандартные для «короткого» текста.Есть ли какая-либо веская причина, по которой так часто выбирается длина 255, кроме красивое круглое число?Является ли это отказом от какого-то момента в прошлом, когда была веская причина (независимо от того, применима ли она сегодня)?
Я, конечно, понимаю, что более жесткий предел был бы более идеальным, если бы вы каким-то образом знали максимальную длину строки.Но если вы используете VARCHAR(255), это, вероятно, указывает на то, что вы не знаете максимальную длину, а только на то, что это «короткая» строка.
Примечание:Я нашел этот вопрос (varchar(255) v tinyblob v tinytext), в котором говорится, что VARCHAR(н) требует н+1 байт памяти для н<=255, н+2 байта памяти для н>255.Это единственная причина?Это кажется произвольным, поскольку вы сэкономите только два байта по сравнению с VARCHAR(256), и вы можете так же легко сохранить еще два байта, объявив VARCHAR(253).
Решение
Исторически сложилось, что 255 символов часто были максимальной длиной VARCHAR
в некоторых СУБД, и иногда они все же оказываются эффективным максимумом, если вы хотите использовать UTF-8 и индексировать столбец (из-за длины индекса ограничения). р>
Другие советы
255 используется потому, что это наибольшее количество символов, которое можно посчитать с помощью 8-битного числа. Это максимизирует использование 8-битного счетчика, не требуя легкомысленного другого целого байта для подсчета символов выше 255.
При использовании этого способа VarChar использует только количество байтов + 1 для хранения вашего текста, поэтому вы можете также установить его на 255, если вы не хотите установить жесткое ограничение (например, 50) на количество символов в поле . р>
Вероятно, потому, что и SQL Server, и Sybase (чтобы назвать два, с которыми я знаком) раньше имели максимум 255 символов в количестве символов в столбце VARCHAR
. Для SQL Server это изменилось в версии 7 в 1996/1997 или около того ... но старые привычки иногда умирали. Р>
Я собираюсь ответить на буквальный вопрос: нет , нет веской причины, по которой вы видите, что VARCHAR (255) используется так часто (действительно, есть причины , как обсуждалось в других ответах, просто не хорошие). Вы не найдете много примеров проектов, которые потерпели катастрофический крах, потому что архитектор выбрал VARCHAR (300) вместо VARCHAR (255). Это может привести к почти полной незначительности, даже если вы говорите о CHAR вместо VARCHAR.
Когда вы говорите 2^8
, вы получаете 256
, но цифры в терминах компьютеров начинаются с цифры 0
. Итак, вы получили 255
и можете проверить его в маске Интернета для IP-адреса или в самом IP-адресе.
11111111 = 255
- максимальное значение 8-битного целого числа: <=>
Это помогает?
Примечание:Я нашел этот вопрос (varchar (255) v tinyblob v tinytext), который говорит, что varchar (n) требует n+1 байт хранения для n <= 255, n+2 байт хранения для n> 255.Это единственная причина?Это кажется довольно произвольным, поскольку вы будете сохранять только два байта по сравнению с Varchar (256), и вы так же легко сохранить еще два байта, объявив его Varchar (253).
Нет.вы не сэкономите два байта, объявив 253.Реализация varchar, скорее всего, представляет собой счетчик длины и незавершенный массив переменной длины.Это означает, что если вы сохраните «привет» в varchar(255), вы займете 6 байт:один байт для длины (число 5) и 5 байт для пяти букв.
1-байтовое число без знака может содержать диапазон [0-255] включительно. Так что, когда вы видите 255, это в основном потому, что программисты думают в основе 10
(шутка?):)
На самом деле, некоторое время 255 был самым большим размером, который вы могли дать VARCHAR в MySQL, и есть преимущества использования VARCHAR по сравнению с TEXT с индексацией и другими проблемами.
Во многих приложениях, таких как MsOffice (до версии 2000 или 2002), максимальное количество символов в ячейке составляло 255. Перемещение данных из программ, способных обрабатывать более 255 символов в поле, в / из этих приложений было кошмаром. В настоящее время лимит все меньше и меньше мешает. Р>
Другая причина может заключаться в том, что в очень старых библиотеках доступа к данным в Windows, таких как RDO и ADO (COM-версия, а не ADO.NET), вам пришлось вызывать специальный метод GetChunk, чтобы получить данные из столбца с более чем 255 символами. , Если вы ограничили столбец varchar значением 255, этот дополнительный код не понадобился. Р>