iweРазве нельзя вместо типа Интегер ввести тип "Штуки"
Можно.
Во всех СУБД, кроме совсем уж игрушечных, есть возможность определения собственных типов данных.
Определяйте "штуки" и работайте.

Но учтите, что всего на 1 миллион записей (а это не много), "штуки" займут:
small - 16 миллионов байт.
integer - 32 миллиона байт
bigint - 64 миллиона.
Плюс такие же веса в индексах.
В конце концов, в Oracle вы можете просто сказать "numeric".

(мы ведь в физическом мире живем, предметы считаем), вместо типов с плавающей точкой - просто "Дробь", ведь есть же "Время" и "Дата"
А такое есть. Decimal
И есть не для "естественности восприятия", а для правильного (и точного) хранения чисел фиксированной разрядности.

Да и вообще, не проще ли для контроля типов ввести просто "Число с точкой" и "Число без точки". Пусть СУБД сама решает, где там у меня предел и максимальное значение, а не забивает мне голову планированием сколько байт у меня на что расходуется...
Думаю, это было бы востребовано, ведь непрофессиональных программистов становится всё больше, это общемировая тенденция, так что уберите ноги, и не пинайте сильно.
Жду ваших мнений... Интересно, что думают по этому поводу профи...
Это всё хорошо, но попробуйте профильтровать сие через среднепаршивые промышленные объемы данных.
Как в части скорости работы, так и в части пространства для хранения.

Это в какой СУБД small занимает 16 байт ?
Бит, конечно же.

Но!
Типы данных давно стандартизованы. И элементарные типы покрывают 99% потребности.
Там, где действительно нужны комплексные типы (GIS и т.п.) - они есть.

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