Существует ли серьезное основание, я вижу VARCHAR (255) используемый так часто (в противоположность другой длине)?
Мое мнение:
я не был бы. В методе/имени класса должно быть сказано, что он делает. Если это не делает, или метод или класс пытаются сделать слишком много, или это называют плохо.
я - поклонник комментария почему, не что. Если не ясно, почему код использует один подход по другому, прокомментируйте его. Если необходимо было добавить неиспользуемую переменную взлома, чтобы обойти ошибку компилятора, прокомментировать почему. Но комментарии как "//Подключение к базе данных" являются знаками плохого кода или плохих политик. Метод под названием ConnectToDatabase () намного лучше. И если это имеет "//, Определяют IP сервера БД" в нем, возможно, который должен быть вытащен к методу, названному "DetermineDbServerIPAddress ()".
Дизайн может быть зарегистрирован, но комментарии обычно плохое место для того уровня документации. Со знанием дизайна и некоторыми комментариями, почему, какой и как должно быть очевидным. Если это не, вместо того, чтобы убедить их комментировать свой код, заставлять их улучшать его.
6 ответов
Исторически 255 символов часто были максимальной длиной VARCHAR в некоторых СУБД, и иногда она все еще оказывается эффективным максимумом, если вы хотите использовать UTF- 8 и индексировать столбец (из-за ограничений длины индекса).
Вероятно, потому что и SQL Server, и Sybase (чтобы назвать два, с которыми я знаком) использовали максимум 255 символов в количестве символов в столбце VARCHAR . Для SQL Server это изменилось в версии 7 в 1996/1997 или около того ... но от старых привычек иногда трудно избавиться.
255 используется, потому что это наибольшее количество символов, которое можно подсчитать с помощью 8-битного числа. Это максимизирует использование 8-битного счетчика, без легкомысленного требования еще одного целого байта для подсчета символов выше 255.
При таком использовании VarChar использует только количество байтов + 1 для хранения вашего текста, поэтому вы можете как хорошо установите его на 255, если вы не хотите жесткого ограничения (например, 50) на количество символов в поле.
1-байтовый номер без знака может содержать диапазон [0-255] включительно. Итак, когда вы видите 255, это в основном потому, что программисты думают в базе 10 (понимаете?)
На самом деле, какое-то время 255 было самым большим размером, который вы могли дать VARCHAR в MySQL. , и есть преимущества использования VARCHAR перед TEXT с индексацией и другими проблемами.
Примечание: я нашел этот вопрос (varchar (255) v tinyblob v tinytext), который говорит, что VARCHAR (n) требует n + 1 байт памяти для n <= 255, n + 2 байт памяти для n> 255. Это единственная причина? Это похоже на произвольно, так как вы были бы только экономия двух байтов по сравнению с VARCHAR (256), и вы могли бы точно так же легко сохранить еще два байта объявив его VARCHAR (253).
Нет. вы не сэкономите два байта, объявив 253. Реализация varchar, скорее всего, представляет собой счетчик длины и неограниченный массив переменной длины. Это означает, что если вы сохраните "hello" в varchar (255), вы займете 6 байтов: один байт для длины (число 5) и 5 байтов для пяти букв.
Я собираюсь ответить на буквальный вопрос: нет , нет веской причины, по которой вы видите VARCHAR (255) используется так часто (действительно есть причин , как обсуждалось в других ответах, просто не хорошие). Вы не найдете много примеров проектов, которые потерпели крах из-за того, что архитектор выбрал VARCHAR (300) вместо VARCHAR (255). Это было бы проблемой почти полной несущественности, даже если бы вы говорили о CHAR вместо VARCHAR.