MySQL: зачем использовать VARCHAR (20) вместо VARCHAR (255)?

Отъезд: Справочник по Varchar

Короче говоря, особой разницы нет, если вы не превысите размер 255 в своем VARCHAR, что потребует еще одного байта для префикса длины.

Длина указывает на большее ограничение данных, хранящихся в столбце, чем на что-либо еще. Это по своей сути также ограничивает МАКСИМАЛЬНЫЙ размер хранилища для столбца. IMHO, длина должна иметь смысл в отношении данных. Если вы храните номер социального страхования #, нет смысла устанавливать длину 128, даже если это ничего не стоит в хранилище, если все, что вы на самом деле храните, - это SSN.

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

Например, если вы храните почтовый индекс Великобритании, вам нужно всего 8 символов. Установка этого ограничения помогает прояснить тип данных, которые вы храните. Если вы выберете 255 символов, это просто запутает ситуацию.

Я не знаю о mySQL, но в SQL Server он позволяет вам определять поля таким образом, чтобы общее количество используемых байтов было больше, чем общее количество байтов, которые фактически могут быть сохранены в записи. Это плохо. Рано или поздно вы получите строку, в которой достигнут предел и вы не можете вставить данные.

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

Кроме того, да, вы не хотите, чтобы люди помещали 200 символов в поле, где максимальное значение должно быть 10. Если они это сделают, это почти всегда неверные данные.

Вы говорите, что я могу ограничить это на уровне приложения. Но данные не попадают в базу данных только из одного приложения. Иногда его используют несколько приложений, иногда данные импортируются, а иногда исправляются вручную из окна запроса (например, обновите все записи, чтобы добавить 10% к цене). Если какой-либо из этих других источников данных не знает о правилах, которые вы вводите в свое приложение, у вас будут плохие, бесполезные данные в вашей базе данных. Целостность данных должна быть обеспечена на уровне базы данных (что не мешает вам также проверять, прежде чем вы попытаетесь ввести данные), иначе у вас нет целостности. Кроме того, по моему опыту, люди, которые слишком ленивы при проектировании своей базы данных, часто также слишком ленивы, чтобы на самом деле вводить ограничения в приложение, а проверка целостности данных вообще отсутствует.

У них есть слово для баз данных без целостности данных - бесполезно.

Существует семантическая разница (и я считаю, что это единственное отличие): если вы попытаетесь заполнить 30 непробельных символов в varchar (20), это приведет к ошибке, тогда как для varchar (255) это будет успешно. Так что это в первую очередь дополнительное ограничение.

Что ж, если вы хотите разрешить более крупную запись или, возможно, ограничить размер записи.

Например, у вас может быть first_name как VARCHAR 20, но, возможно, street_address как VARCHAR 50, поскольку 20 может быть недостаточно места. В то же время вы можете контролировать, насколько большим может стать это значение.

Другими словами, вы установили потолок того, насколько большим может быть конкретное значение, чтобы теоретически предотвратить слишком большой размер таблицы (и, возможно, записей индекса / указателя).

Вы можете просто использовать CHAR, который также имеет фиксированную ширину, но в отличие от VARCHAR, который может быть меньше, CHAR заполняет значения (хотя это ускоряет доступ к SQL.

С точки зрения производительности базы данных я не верю, что будет разница.

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