по типу данных

@arava · Регистрация: 30.06.2014

Студворк — интернет-сервис помощи студентам

Поясните пожалуйста такой момент:

К примеру при проектировании базы данных меня устроит что поле id будет не очень большое(1000 может 2000).
Выбрать тип данных я могу допустим

SQL
1
SMALLINT UNSIGNED ,от 0 до 65535

и это будет норм.Но вижу что выбирают для такой задачи тип данных к примеру

SQL
1
INT

или

SQL
1
BIGINT

и присваивают параметр (4),т.е. 4 симовола,по факту 5.

Почему так делают?почему не сделать

SQL
1
SMALLINT(4)

?

Добавлено через 2 минуты
или если выбирается тип данных

SQL
1
BIGINT

с огромным диапазоном значений то зачем присваивать ему параметр (4),не проще ли выбрать другой тип данных???

@Anvano · 09.08.2016, 23:35

Вы точно тщательно документацию читали?

Ваша

SQL
1
BIGINT(4)

НЕ означает, что в данном поле можно хранить только 4 значные числа.

В это поле по-прежнему влезут любые числа от -9223372036854775808 до 9223372036854775807 (если SIGNED)

Четверка тут - это так называемый display width - чистой воды метаданные, просто как указание приложению, использующему базу, что "надо бы все числа из этого столбца, в которых меньше 4 цифр, отобразить с шириной в 4 цифры". А уже дело приложения, следовать этому указанию или нет.
На хранение (и на размер в байтах) чисел в БД эта циферка НИКАК не влияет.

P.S: Если добавить еще спецификатор ZEROFILL - то база автоматом будет дополнять числа менее 4 цифр нулями слева до 4 знаков. Но если число более 4 цифр - то оно будет выведено полностью "как есть" без обрезания.

@arava · 10.08.2016, 01:06 **[ТС]**

Спасибо Вам.Не совсем понятно следующее:

SQL
1
BIGINT (4)

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

@Anvano · 10.08.2016, 07:27

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

Зависит от объемов вашей БД, очевидно, что это скажется в виде увеличения требуемого места на диске под хранение данных. Т.к. BIGINT занимает 8 байт, а SMALLINT - 2 байта.

Так что, если у вас БД нацелена на хранение каких-то сырых данных (например CDR с коммутатора или значений каких-то датчиков), то правильный выбор типа может существенно сэкономить дисковое пространство.

При гонянии данных по сети, зависит от драйвера и используемого протокола. Данное направление я не прорабатывал, но есть вероятность получить повышенную нагрузку на канал, если вместо SMALLINT используется BIGINT.

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

Новые блоги и статьи Все статьи Все блоги /
Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .	Знаешь почему 90% людей редко бывают счастливыми? kumehtar 14.04.2026 Потому что они ждут. Ждут выходных, ждут отпуска, ждут удачного момента. . . а удачный момент так и не приходит.	Фиксация колонок в отчете СКД Maks 14.04.2026 Фиксация колонок в СКД отчета типа Таблица. Задача: зафиксировать три левых колонки в отчете. Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка) / / . . .
Настройки VS Code Loafer 13.04.2026 { "cmake. configureOnOpen": false, "diffEditor. ignoreTrimWhitespace": true, "editor. guides. bracketPairs": "active", "extensions. ignoreRecommendations": true, . . .	Оптимизация кода на разграничение прав доступа к элементам формы Maks 13.04.2026 Алгоритм из решения ниже реализован на нетиповом документе, разработанного в конфигурации КА2. Задачи, как таковой, поставлено не было, проделанное ниже исключительно моя инициатива. Было так:. . .	Контроль заполнения и очистка дат в зависимости от значения перечислений Maks 12.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: реализовать контроль корректности заполнения дат назначения. . .	Архитектура слоя интернета для сервера-слоя. Hrethgir 11.04.2026 В продолжение https:/ / www. cyberforum. ru/ blogs/ 223907/ 10860. html Знаешь что я подумал? Раз мы все источники пишем в голове ветки, то ничего не мешает добавить в голову такой источник, который сам. . .

@Anvano 476 / 239 / 114 Регистрация: 12.05.2016 Сообщений: 647
	10.08.2016, 07:27
	Ну если прямо заранее в отрыве от базы известно, что будут только четырехциферные числа.. Зависит от объемов вашей БД, очевидно, что это скажется в виде увеличения требуемого места на диске под хранение данных. Т.к. BIGINT занимает 8 байт, а SMALLINT - 2 байта. Так что, если у вас БД нацелена на хранение каких-то сырых данных (например CDR с коммутатора или значений каких-то датчиков), то правильный выбор типа может существенно сэкономить дисковое пространство. При гонянии данных по сети, зависит от драйвера и используемого протокола. Данное направление я не прорабатывал, но есть вероятность получить повышенную нагрузку на канал, если вместо SMALLINT используется BIGINT. В плане самих манипуляций с числами - я не вижу особой разницы, т.к. в современной 64 битной архитектуре - гораздо большие числа целиком помещаются в регистрах процессора и обрабатываются за один такт, то бишь для процессора разницы вообще нет, какого размера числа молотить. 1