Там недостатки к использованию универсального varchar (255) для всех основанных на тексте полей?

97
задан Nathan Koop 29 August 2012 в 18:45
поделиться

6 ответов

В устройстве хранения данных, VARCHAR(255) достаточно умно для хранения только длины, в которой Вы нуждаетесь на данной строке, в отличие от этого CHAR(255), который всегда хранил бы 255 символов.

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

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

Вы также хотели бы знать, что это "увеличивающее" поведение означает, что строка, объявленная с utf8 набором символов, увеличивает к трем байтам за символ даже для строк, которые Вы снабжаете однобайтовым содержанием (например, ASCII или latin1 символы). И аналогично набор символов utf8mb4 заставляет строку увеличивать к четырем байтам за символ в памяти.

Так VARCHAR(255) в utf8, хранящем короткую строку как "Никакое мнение", берет 11 байтов на диске (десять символов более низкого набора символов, плюс один байт для длины), но требуется 765 байтов в памяти, и таким образом во временных таблицах или отсортированных результатах.

я помог пользователям MySQL, которые невольно часто составляли временные таблицы на 1.5 ГБ и заполняли их дисковое пространство. У них было много из VARCHAR(255) столбцы, которые на практике сохранили очень короткие строки.

Лучше определять столбец на основе типа данных, которые Вы намереваетесь хранить. Это обладает преимуществами для осуществления связанных с приложением ограничений, как другие люди упомянули. Но это обладает физическими преимуществами для предотвращения отходов памяти, которые я описал выше.

трудно знать, каков самый длинный почтовый адрес, конечно, который является, почему многие люди выбирают длинное VARCHAR, который, конечно, более длинен, чем какой-либо адрес. И 255 обычно, потому что это - максимальная длина VARCHAR, для которого длина может быть закодирована одним байтом. Это был также максимум VARCHAR длина в MySQL, более старом, чем 5,0.

126
ответ дан Bill Karwin 24 November 2019 в 05:26
поделиться

Я с Вами. Суетливое внимание к деталям невыносимо и ограничило значение.

Когда-то давно, диск был драгоценным товаром, и мы раньше потели маркеры для оптимизации его. Цена устройства хранения данных упала фактором 1 000, делая время проведенным на сжатие каждого байта менее ценный.

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

Однако, если Вы переоцениваете свои размеры или Ваши фактические размеры данных, являются переменными, Вы будете волновать опустошительное пространство с полями CHAR. Данные закончатся менее плотно упакованный (ведущий к большему количеству ввода-вывода для больших извлечений).

Обычно выигрыши в производительности от попытки поместить размер на переменные поля незначительны. Можно легко сравнить при помощи VARCHAR (255) по сравнению с CHAR (x), чтобы видеть, можно ли измерить различие.

Однако иногда, я должен обеспечить "маленькую", "среднюю", "большую" подсказку. Таким образом, я использую 16, 64, и 255 для размеров.

13
ответ дан S.Lott 24 November 2019 в 05:26
поделиться

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

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

Теперь, сложность varchar полей - то, что Вы не можете легко определить местоположение записи через, он - рекордное число. Когда у Вас есть размер строки фиксированной длины (с полями фиксированной длины), это тривиально для вычисления дискового блока, на который указывает идентификатор строки. С переменной длиной rowsize, такие движения из окна.

Так, теперь необходимо поддержать некоторый индекс рекордного числа, точно так же, как любой другой первичный ключ, ИЛИ необходимо сделать устойчивый идентификатор строки, который кодирует детали (такие как блок, и т.д.) в к идентификатору. Если бы Вы делаете это, тем не менее, идентификатор должен был бы быть повторно вычислен, если когда-нибудь строка перемещена в персистентное устройство хранения данных. Никакое грандиозное предприятие, просто не должно переписывать все элементы индекса и удостоверяться Вы, любой a) никогда не представляйте его потребителю или b) никогда не утверждает, что число надежно.

, Но так как у нас есть varchar поля сегодня, единственное значение varchar (16) по varchar (255) - то, что DB осуществит 16 символьных пределов на varchar (16). Если модель DB, как предполагается, является на самом деле представительной для физической модели данных, то наличие полевых длин может быть значимым. Если, однако, это - просто "устройство хранения данных", а не "модель И устройство хранения данных", нет никакой потребности вообще.

Тогда просто необходимо различить между текстовым полем, которое является индексируемым (такой varchar) по сравнению с чем-то, что не является (как текст или поле CLOB). Индексируемые поля имеют тенденцию иметь предел на размер для упрощения индекса, тогда как поля CLOB не делают (в причине).

13
ответ дан Will Hartung 24 November 2019 в 05:26
поделиться

По моему опыту, если Вы позволите тип данных 255 символов, некоторый глупый пользователь (или некоторый опытный тестер) на самом деле заполнят это.

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

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

5
ответ дан BradC 24 November 2019 в 05:26
поделиться

Это - хорошая практика для выделения только немногим более, чем, в чем Вы нуждаетесь. Номера телефона никогда не шли бы это большое.

Одна причина состоит в том, что, если Вы не проверяете против больших записей, несомненно кто-то будет использовать все, которые существует. Тогда у Вас могло бы закончиться пространство в Вашей строке. Я не уверен в пределе MySQL, но 8060 макс. rowsize в SQL MS.

А более нормальное значение по умолчанию было бы 50, по моему скромному мнению, и затем увеличилось бы, где потребность доказывает его.

0
ответ дан dove 24 November 2019 в 05:26
поделиться

В дополнение к соображениям размера и производительности при установке размера varchar (и, возможно, более важно, поскольку хранение и обработка становятся дешевле каждую секунду), недостаток использования varchar (255) " просто потому, что "снижается целостность данных .

Определение максимальных пределов для строк - это хороший способ , чтобы предотвратить попадание длинных, чем ожидалось, строк в РСУБД и вызвать переполнение буфера или исключения / error позже при извлечении и анализе значений из базы данных, которые длиннее (больше байтов), чем ожидалось.

Например, если у вас есть поле, которое принимает двухсимвольные строки для сокращений стран, то у вас нет никаких причин ожидать, что вы пользователи (в данном контексте программисты) для ввода полных названий стран. Поскольку вы не не хотите, чтобы они вводили «Антигуа и Барбуда» (AG) или «Остров Херд и острова Макдоналда» (HM), вы не разрешаете это на уровне базы данных. Кроме того, вполне вероятно, что некоторые программисты еще не обработали RTFM документации по проекту (, которая наверняка существует ), чтобы знать, что этого не следует делать.

Задайте в поле два символа и позвольте СУБД справиться с этим ( либо изящно путем усечения, либо изящно путем отклонения их SQL с ошибкой).

Примеры реальных данных, у которых нет причин превышать определенную длину:

  • Канадские почтовые индексы имеют формат A1A1A1 и всегда равны 6 длиной , даже для Санта-Клауса (6 символов не включают пробел, который можно указать для удобочитаемости).
  • адреса электронной почты - до 64 байтов до @, до 255 байтов после . Никогда больше, чтобы вы не сломали Интернет.
  • Номера телефонов в Северной Америке никогда не содержат более 10 цифр (без кода страны).
  • Компьютеры, работающие (последние версии) Windows, не могут иметь имена компьютеров длиннее 63 байтов , но более 15 не рекомендуется и приведет к поломке вашей серверной фермы Windows NT.
  • Аббревиатуры штатов состоят из 2 символов (например, коды стран, приведенные в примере выше)
  • Номера отслеживания ИБП : 18, 12, 11 или 9 - символы длинные. 18-значные номера начинаются с «1Z», а 11-значные номера начинаются с «T», что заставляет задуматься, как они доставляют все эти пакеты, если они не знают разницы между буквами и цифрами.

И так далее. ...

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

24
ответ дан 24 November 2019 в 05:26
поделиться
Другие вопросы по тегам:

Похожие вопросы: