Есть ли веская причина, по которой VARCHAR (255) используется так часто (в отличие от другой длины)?

В нескольких курсах, книгах и заданиях я видел текстовые поля, определенные как VARCHAR (255) как тип значения по умолчанию для "короткого" текста. Есть ли веская причина, что длина 255 выбрана так часто, за исключением хорошего круглого номера? Является ли это задержкой с того времени в прошлом, когда была веская причина (независимо от того, применяется ли она сегодня)?

Я понимаю, конечно, что более жесткий предел был бы более идеальным, если бы вы как-то знали максимальную длину строки. Но если вы используете VARCHAR (255), это, вероятно, указывает на то, что вы не знаете максимальную длину, только то, что это "короткая" строка.

Примечание: я нашел этот вопрос (varchar (255) v tinyblob v tinytext), в котором говорится, что VARCHAR (n) требует n + 1 байт памяти для n <; = 255, n + 2 байта хранения для n > 255. Это единственная причина? Это кажется произвольным, так как вы сохранили бы только два байта по сравнению с VARCHAR (256), и вы могли бы легко сохранить еще два байта, объявив его VARCHAR (253).

Ответ 1

Исторически 255 символов часто были максимальной длиной VARCHAR в некоторых СУБД, и иногда она по-прежнему заканчивается как эффективный максимум, если вы хотите использовать UTF-8 и индексировать столбец (из-за длины индекса ограничения).

Ответ 2

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

При использовании этого способа VarChar использует только количество байтов + 1 для хранения вашего текста, поэтому вы можете также установить его на 255, если только вам не нужен жесткий предел (например, 50) по количеству символов в поле.

Ответ 3

Вероятно, потому что и SQL Server, и Sybase (для обозначения двух, с которыми я знаком) используются, чтобы иметь максимум 255 символов в количестве символов в столбце VARCHAR. Для SQL Server это изменилось в версии 7 в 1996/1997 годах или так... но старые привычки иногда сильно умирают.

Ответ 4

Я отвечу на буквальный вопрос: нет, нет веской причины, по которой вы часто встречаете VARCHAR (255) (есть причины, о которых говорится в других ответах, просто не хорошие). Вы не найдете много примеров проектов, которые потерпели неудачу катастрофически, потому что архитектор выбрал VARCHAR (300) вместо VARCHAR (255). Это было бы проблемой почти полного незнания, даже если бы вы говорили о CHAR вместо VARCHAR.

Ответ 5

Когда вы говорите 2^8, вы получаете 256, но числа в терминах компьютеров начинаются с номера 0. Итак, тогда вы получили 255, вы можете исследовать его в маске интернета для IP-адреса или самого IP-адреса.

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

Помогает ли это?

Ответ 6

Примечание: я нашел этот вопрос (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 байтов для пяти букв.

Ответ 7

Беззнаковый 1 байтовый номер может содержать диапазон [0-255] включительно. Итак, когда вы видите 255, это происходит главным образом потому, что программисты думают в базе 10 (получить шутку?):)

На самом деле, на некоторое время 255 был самым большим размером, который вы могли бы предоставить VARCHAR в MySQL, и есть преимущества использования VARCHAR над TEXT с индексацией и другими проблемами.

Ответ 8

Во многих приложениях, таких как MsOffice (до версии 2000 или 2002), максимальное количество символов на ячейку составляло 255. Перемещение данных из программ, способных обрабатывать более 255 символов в поле в/из этих приложений, было кошмаром. В настоящее время предел все меньше и меньше препятствует.