Поддерживаю вопрос!

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


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

Соответственно, если это так, то варинт не пойдёт для ссылочности. Для хранения полезной инфы, но не для внутренних целей.


Если же алгоритм для всех целочисленных типов один, то мысль интересная.

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


Экономия аж 20-30 байт на ключе элемента справочника и пары терабайт на базе вылезет в ужаснейший гемор когда ваш запланированных список бизнесущностей на 20 бит вдруг вылезет за, казалось бы, такие широкие пределы. Аж мульон! Разве может быть в номенклатуре продукции быть более мульона наименований? "сарказм"

Проектировать надо с учётом области работы, только и всего. С пониманием, что делаешь. Каждая позиция номенклатуры - это экземпляр типа, а не тип. Соответственно под это больше. А вот кол-во типов сущностей намного меньше по определлению. И таблица, в которой хранятся экземпляры, определённо будет меньше, если ссылка на тип будет не бигинт, а медиуминт2.

Item (ID bigint PK, TypeID mediumint2 FK, ...)