Что такое исторические таблицы
Что проверяют
Умеете ли вы проектировать хранение так, чтобы отвечать на вопрос «как это выглядело на дату», и понимаете ли разницу между историей событий и историей атрибутов. Для инженера данных это ежедневная работа: отчёт за прошлый месяц обязан пересчитываться одинаково и сегодня, и через год.
Как отвечать
Историческая таблица хранит не текущее состояние, а последовательность состояний: у строки есть интервал действия и признак актуальности.
Базовая форма это медленно меняющееся измерение второго типа: бизнес-ключ остаётся, добавляются суррогатный ключ версии, границы valid_from и valid_to, флаг актуальной записи. При изменении отслеживаемых атрибутов предыдущая версия закрывается, пишется новая. Выборка на дату превращается в предикат по интервалу.
Дальше стоит упомянуть две оси времени: когда факт был верен в реальности и когда мы о нём узнали. Если источник присылает исправления задним числом, без второй оси старый отчёт перестанет воспроизводиться.
Альтернативы называют по цене чтения и записи: полные снимки на дату (просто, дорого по объёму), журнал изменений через захват изменений (дёшево пишется, состояние нужно собирать), системное версионирование средствами СУБД.
Где спотыкаются
Путают журнал операций с историей. Таблица платежей или отгрузок уже неизменяемый факт, версионировать в ней нечего. История нужна там, где значение перезаписывается: цена, тариф, категория товара, закреплённый за клиентом менеджер.
Пишут новую версию на каждую загрузку, не сравнивая значимые колонки. Таблица растёт линейно времени, а вопрос «когда поменялся тариф» тонет в тысячах одинаковых версий.
Не договариваются о границах интервала: где-то конец включительно, где-то нет, где-то открытый конец это NULL, где-то далёкая дата. Соединение по периоду начинает давать то дубли, то дыры, и ловится это уже на расхождении витрин.