⭐️ Insert-only факты и snapshot-измерения — быстрый путь к стабильным таблицам

Большинство бизнес-вопросов в нормальных компаниях решается через обычные fact + dimension таблицы в стиле Кимбелла. Без извращений.

Предлагаю тебе практичный сетап:

1️⃣ Insert-only fact таблицы
Простое правило:

Вставили строку в факт — больше её не обновляем (кроме осознанного backfill).

Плюсы:
🔘 история событий не переписывается
🔘 легче дебажить: «вот, в этот день такой набор фактов и был»
🔘 меньше сложных merge-операций и конфликтов

2️⃣ Snapshot dimension таблицы
Вместо сложных SCD2 везде:
🔘 на каждый прогон пайплайна полностью пересобираем измерение (snapshot)
🔘 храним несколько лет истории снапшотов
🔘 SCD2 оставляем только там, где реально нужно

3️⃣ Одно зерно на таблицу
Никаких "и по пользователю, и по заказу, и по клику в одной таблице". Только один чёткий grain.

4️⃣ Флаги не плодим, чтобы не получить ад с флагами
Если колонка зависит от какого-то флага — лучше разнести в явно названные колонки, а не "если flag = 1, тогда тут другое значение".

5️⃣ Нейминг и ключи
🔘 использовать вменяемые нейминги (хотя бы кимбелловские)
🔘 surrogate key можно не городить, если технология позволяет нормально джойниться по натуральным ключам

6️⃣ View как интерфейс
Для пользователей всегда отдаём view, а не саму таблицу:
🔘 можно менять схему под капотом
🔘 можно вьюхой выбирать актуальный snapshot
🔘 пользователям не больно

Это очень скучные правила, но именно они позволяют делать модели быстро и не умирать от рефакторинга каждые 3 месяца.

〰️〰️〰️〰️〰️〰️〰️〰️
Порядок в DWH

#dev #de #dwh