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

Ответ 1

Отъезд: Ссылка на Varchar

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

Длина указывает больше ограничений на данные, хранящиеся в столбце, чем что-либо еще. Это по сути ограничивает размер хранилища MAXIMUM для столбца. ИМХО, длина должна иметь смысл в отношении данных. Если вы сохраняете Social Security #, нет смысла устанавливать длину до 128, даже если это не стоит вам ничего в памяти, если все, что вы на самом деле сохраняете, является SSN.

Ответ 2

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

Ответ 6

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