Задумался тут над вопросами реализации модели ВЕРО и плавно перешёл (через избыточность ссылочных полей в центральной таблице объектов) к вопросу о недостаточности целочисленных типов в ms sql.

Ну что это в самом деле? Есть int, есть bigint. Разница между ними 4 байта и 4 294 967 раз. Ничего себе разгон! Есть smallint, есть int. Разница между ними уже не такая огромная, "всего" 2 байта и 65000 с лишним раз.

И в том, и в другом случае это слишком большие интервалы.

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

Парадокс, люди занимавшиеся созданием СУБД подумали о собссно ссылочной структуре в последнюю очередь. Чем они руководствовались, понять трудно. Однако очевидно, что размер хранения целых чисел в 1, 2, 4 и 8 байтов продиктован "красотой" этого ряда (всё как любят тру программисты вышедшие из математиков, всё это степени числа 2), но никак не практическими задачами.

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

Вот под это и нужно затачивать типы целочисленных данных. Потому как в ПЕРВУЮ очередь это вовсе не типы для хранения кол-ва мороженного на складе молокозавода. А типы для хранения номеров строк в таблицах.


Даже удивительно, что на это никто из создателей не обратил внимание, ведь даже термин реляционная идёт впереди термина база данных. Потому как реляционность важнее "базоданности".

(А вот в других РСУБД об этом подумали, хотя тоже вариант там дополнительный только один: медиуминт в MySQL)

Я полагаю, что типы целочисленных данных должны идти просто с шагом в 1 байт, и кому нужно, тот сам подберёт себе нужный диапазон.

Но сильнее всего конечно нужен медиуминт, потому как именно в этом диапазоне располагается значительная часть бизнес-задач, назовём это так. Ну скажем кол-во типов объектов ещё может дойти до десятков тысяч (2 байта), но вряд ли достигнет верхнего порога в 8 с лишним миллионов (3 байта).

Для примера есть таблица на 10 млрд записей. В ней есть поле с ID некой сущности. Сущностей не так много, но ставить smallint несколько опрометчиво. Мало ли как дело пойдёт? И назначают обычный инт, т.е. 4 байта.

Если же у нас был бы тип медиуминт, то экономия составила бы 10 млрд байт, т.е. 9.3 Гб. Оно вроде как по нынешним временам и не так много, но таблица такая не одна, помимо хранения самой таблицы на дисках, есть ещё чтение, запись, оперативка, tempdb и проталкивание данных через сети и системы обмена. В общем прилично набегает.

P.S. Более того! Sql server вообще-то умеет (умеет, когда захочет, что называется) хранить данные побитово. И ничто не мешает сделать типы данных с размером в 1.5 и 2.5 байт. Т.е. в 12 и 20 бит. Если такие типы данных ограничить только положительными значениями, то они были бы очень хороши для идентификаторов справочников (12 бит = 0 - 4095) или иных бизнес-сущностей (20 бит = 0 - 1 048 575).

1. "unsigned int" Было бы неплохо, хотя вот именно это не так остро нужно. Надо брать у конкурентов удачные решения.

2. "binary/varbinary". А поиск так же быстро будет работать? Это риторический вопрос.

"по int сравнение будет быстрее, потому что для него есть поддержка процессора: сравнение двух целых чисел - это одна инструкция процессора."

Akina,

исходя из этой логики:

1. Непонятно, как получилось, что есть типы данных на 1 и 2 байта. Раз у регистра строго 4 (теперь уже 8). Если регистр 4 (8) байта, то можно иметь от 1 до 4 байт (до 8). Типы данных на 1 и 2 байта есть, почему нельзя иметь 3? Вы придумываете сложность на ровном месте.

2. Поиск в MySQL по медиуминту должен быть не быстрее, чем по бигинту. Это так?

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

Ну вот например:

"Операции массового импорта и экспорта
При экспорте данных, даже в собственном формате, данные выводятся в распакованном формате строк. Поэтому размер экспортированного файла данных может значительно превысить размер исходных данных.
При импорте данных, если для целевой таблицы было включено сжатие, данные будут преобразованы подсистемой хранилища в сжатый формат строк. По сравнению с импортом данных в распакованную таблицу такой импорт может потребовать больше ресурсов ЦП.
Если массовый импорт данных производится в кучу с включенным сжатием страниц, то при вставке данных операция массового импорта попытается применить к ним сжатие страниц."


Я про что и говорил: БД не в вакууме вертится, а в среде. И в этой среде пересылка данных туда сюда тоже требует затрат. Уменьшение напрямую размера данных уменьшает затраты, а сжатие данных в самой БД нет.

Вы так возражаете? Это ж подтверждение: был бы медиуминт, вы бы его заложили сразу и ничего переделывать не пришлось бы!


А вот шобы bigint мешался "из-за размера" - такого не припомню.
"9.3 Гб" на таблице, содержащей десяток полей - это ниочем.

Речь не про экономию дискового пространства, хотя и это важно. А про скорость работы системы в целом.

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


А вообще по хорошему всех этих бигинтов и смолинтов быть не должно, а должны быть инты:

int1, int2, ..., int8 где число означает кол-во байт.

Отличный запрос! Мне понравилось.


На одной из основных баз получается оверхед 25 TB. (Не уверен на 100%, что не ошибся).

Вооот! А это помимо дисков и всё остальное окружение, которое должно через себя пропустить все эти лишние объёмы.