Имеет ли смысл ограничивать длину varchar?

Question

[AlikDex]

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

То же касается и других типов данных. Например int (про таблицу типов инт и количество байт я в курсе, речь именно о искусственном ограничении)

Answer 1

[Оптимус Пьян]

Обязательно нужно ограничивать!
То же самое в int если знаете что числа будут небольшие - используйте smallint

Comments

[AlikDex]

Насчет типов написал. тотже smallint дефолтом идет как smallint(3), но ведь можно выставить smallint(1). Что это даст?

В случае с varchar чем аргументируете необходимость ограничивать? Насколько я понял из документации, толку ноль от икусственных ограничений. Тем не менее такое практикуют. Да и сам я считал что это выгодно в плане экономии памяти, но так ли это на самом деле?

[Оптимус Пьян]

AlikDex: если вам нужен smallint(1) то вам нужен не smallint а tinyint тогда Почему? Вот читайте g.zeos.in/?q=%D1%80%D0%B0%D0%B7%D0%BC%D0%B5%D1%80%...

[AlikDex]

Дмитрий: блин. неверно написал про smallint. Оно по дефолту (5) ведь
ок. разницы нет. берем tinyint (3) и tinyint(1) по факту оба валидны, но что даст искусственное ограничение?

[Оптимус Пьян]

AlikDex: скорость поиска

[AlexeyVD]

tinyint(1) и tinyint(3) занимают 1 байт и принимают значения от -128 до 127 или от 0 до 255, если unsigned. Число в скобках - всего лишь количество отображаемых символов. Ни на скорость, ни на место оно не влияет.

[Оптимус Пьян]

AlexeyVD: Я загуглил, вы правы, ни на что не влияет

Answer 2

[Петр]

Для хранения md5 хешей лучше еще вместо varchar использовать тип char(32)

Comments

[AlikDex]

а для емейлов\имен\никнеймов? длина таких строк плавающая, и длинее 64 символов практически не бывает.

[Петр]

AlikDex: "для емейлов\имен\никнеймов" - varchar.

[Андрей Юрченко]

Не забываем про BINARY(16) для md5

[Петр]

Андрей Юрченко: Можно и так, но менее удобно для использования. Как правило всегда идет работа в коде приложения с md5 хешами как строкой. С BINARY(16) добавляются лишнии конвертации.

[Андрей Юрченко]

Петр: но тут вам не стоит забывать что вам важнее, почить во время отладки или компактно хранить, а дописать к запросу hex(`md5`) лично у меня лени не вызывает, тут скорее вопрос личных приоритетов.

Answer 3

[AlexeyVD]

VARCHAR - строки переменной длины. Если в VARCHAR(255) записать 32-байтную строку, то и в памяти строка займет 32 байта + 1 байт на хранение длины строки.
А вот поле CHAR(255) всегда будет занимать 255 байт (незаполненный данные при хранении заполняются пробелами).
Так что если в будущем длина поля может поменяться, и строгое ограничение длины в базе не критично, то смело пишите VARCHAR(255). В базе будет храниться ровно столько данных. сколько вы туда запишете.

По целочисленным типам, как уже написали - если знаете диапазон значений в этом поле и уверены, что со временем величины из этого диапазона не выйдут, то используйте максимально длизкий к этому диапазону тип для хранения. Например, если значения в столбце никогда не превысят 127, то достаточно поля TINYINT.

Answer 4

[Артемий]

Для данных фиксированной длины, лучше использовать поля фиксированной длины. База будет эффективней работать. Это по производительности. А с точки зрения целостности данных база - последняя линия обороны. Поэтому лучше чтобы параметры полей соответствовали проекту. А то потом где-то всплывет что-нибудь. Или будет глючить неуловимо.