Критик,

+1
это наверное который трёх-байтный (date) или 4-х байтный (smalldatetime, ближе к вопросу ТСа) против 4x байтного int - вполне хватает для реальных бизнес диапазонов компаниям не торгующим с дореволюционных времён
https://docs.microsoft.com/en-us/sql/t-sql/functions/date-and-time-data-types-and-functions-transact-sql?view=sql-server-ver15

p.s. по факту даже те-же в отсталом технологическом цикле легаси меняют каждые лет 20-30,
а уж о большинстве организаций так миграция практически нескончаемая каждые лет 5..

полный диапазон 4х байтного int (4 млрд.) вполне умещается в 150 лет посекундно.
а 2х байтного smallint (-32К~+32К или 2^16 >> 65536) хватает на почти на 180 лет для date но не вмещает полный посекундный день
если лениво делать всё отдельно (часы/минуты/дни-годы) то получaтся те-же 4 байта 1B(tinyint)+1B(tinyint)+2B(smallint), причём в различных ключах (т.е. дороже)

п.п.с.
у меня в табличных моделях (с учётом In-Memory, на одну модель сервера от 32GB, хотя есть и по 16GB, но фокус на CPU уже больше)
в последнее время в измерениях по ключу счёт уже пошел на десятки миллионов (до сотни не дотягиваем)
с учётом возможности партиционирования табличной модели - в принципе по стресс-тестам на латентность
(от выстрела запроса в сессию, до получения полного result/dataset на клиенте)
работает вполне приемлемо (по крайней мере для наших целей).

ShIgor,

ну да, немного унесло, так-то если в пределах MD оставаться то получается выбор
8 байтов (BigInt,Currency,Date,Double), 4 байта (Integer, Single), 2 байта (SmallInt) и 1 байт (TinyInt)
А если только ключами измерения мерить то и того меньше по типам (но то-же по байтам)
Для сценария с единственным измерением получается подходят типы только начиная с 4х байтных
(в 2х байтные даже год посекундно не поместишь)
покрывают требования до 136 лет, но 4х миллиардно-ключевое измерение железо навряд-ли нормально потянет,
и скажем на 3 года посекундно полным измерением без пропусков нужно будет
почти 100 млн. строк ключа уместить в измерении, т.е. довольно проблематично
однако реально с учётом не полного дня и рабочего цикла/плотности событий там за 3 года максимум
2-3% из ключей потребуется, т.е. на миллиона три вполне вероятно придётся измерение делать (по млн. на год)

Несколькими сообщениями выше указанный сценарий разбивать на несколько измерений
(два с date/time, или три/4 до часы/минуты/до экстрима:секунды {role-playing с минутами})
- то больше ключей в факты на партиции
т.е. +нагрузка на storage engine, но при этом для In-Memory измерений жизнь намного легче получается.
так что как оптимально сбалансировать разбиение между измерениями/типами данных - зависит от плотности событий в бизнес-процессах компании
но не под все сценарии навигации решения подойдёт, т.к. часто разными измерениями пользоваться будет сильно проблематично
напр. для выбора диапазона событий с 27/12/2019 04:45 ~ до 14/02/2020 17:04
придётся на клиенте/front-end поднапрячься чтобы ненароком не исключить остальные дни по времени
(с датами просто, с измерением часы/минуты - не нужные заморочки, но если в требованиях нет фильтрации часов/минут а только вывод нужен - то проблемы нет)

https://docs.microsoft.com/en-us/analysis-services/multidimensional-models/olap-physical/data-types-in-analysis-services?view=asallproducts-allversions

https://docs.microsoft.com/en-us/analysis-services/multidimensional-models/data-sources-and-bindings-ssas-multidimensional?view=asallproducts-allversions

https://docs.microsoft.com/en-us/analysis-services/tabular-models/data-types-supported-ssas-tabular?view=asallproducts-allversions

TypeBytesBigInt8Currency8Date8Double8Integer4Single4Smallint2Tinyint1