Кот МатроскинС диска читается все равно страница целиком - т.е. единственный кейс, когда от уменьшения размера ключа на 3 байта может быть выигрыш - когда те обьекты, которые раньше лежали на двух и более страницах, умещаются на одну.
Для простенького справочника из 256 элементов максимум - не очень вероятный случай.Экономия не на справочнике, а в таблицах, которые его используют.

Огромная таблица фактов может содержать только ссылки на справочники, и вышеописанный подход "экономии на типах" может уменьшить многотерабайтное хранилище в пару раз.
JesterOKЯ новичок, и вопрос соответсвенный: как нужно планировать индексы ??Ну, индексы в этом вопросе вообще ни при чём :-)
JesterOKЯсоздаю справочник по типу: id, figura. где поле id = UNSIGNED TINYINT. ведь 255 записей мне по идее должно хватить на все про все.

и чтобы пользователь не вводил ID, ведь он даже не представляет что это, я делаю автоинкремент.

Но автоинкремент работает так что если я удалил из 1-2-3-4-5 запись 4, то автоинкремент добавит следующую позицию 6.Пользователи обычно такими справочниками не управляют, это делают программисты, либо администраторы данных. Так что лучше отказаться от автоинкремента и управлять идентификаторами самому. Это, конечно, зависит от справочников, но для маленьких правочников получается обычно так.
JesterOKНо автоинкремент работает так что если я удалил из 1-2-3-4-5 запись 4, то автоинкремент добавит следующую позицию 6.И, наконец, главный вопрос - а как, собственно, планируется удалять значения из справочника? А ссылок на них не было? А в исторических данных, в старых отчётах?
Удаление из справочника - это вообще большая редкость, обычно так не делают при проектировании модели данных.

Кот Матроскинalexeyvgпропущено...
Экономия не на справочнике, а в таблицах, которые его используют.

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

Только ссылки на справочники из 256 элементов? ;) Как-то не очень вероятно имхо.Ну я обобщённо говорю, вообще про необходимость учёта размера хранения при выборе типа для некоторых случаев.

Допустим, была таблица фактов - пара полей-ссылок типа INT, поле datetime, поле NUMERIC(38)
То есть 4+4+8+17 = 33 байт
Сделали пару полей-ссылок типа TINYINT, SMALLINT, поле INT (ссылка на календарь, ну или тип SMALLINT, тоже 4 байта), поле real
Получилось 1+2+4+4 = 12 байт
Почти в три раза, было хранилище к примеру 100 террабайт, стало 40, экономия.

alexeyvgДопустим, была таблица фактов - пара полей-ссылок типа INT, поле datetime, поле NUMERIC(38)
То есть 4+4+8+17 = 33 байт
Сделали пару полей-ссылок типа TINYINT, SMALLINT, поле INT (ссылка на календарь, ну или тип SMALLINT, тоже 4 байта), поле real
Получилось 1+2+4+4 = 12 байт
Почти в три раза, было хранилище к примеру 100 террабайт, стало 40, экономия.Ой, получилось 11 байт, экономия в 3 раза.