Denormalization

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

Типичные паттерны:

| Паттерн | Пример | Цена согласованности | |---------|--------|----------------------| | Избыточный столбец | `orders.customer_name` скопирован из `users` | Смена имени → backfill orders | | Кэш агрегата | `product.order_count` | Инкремент на каждой позиции | | Materialized view | ночной rollup выручки | Допустим lag refresh | | JSON-snapshot | позиция корзины с ценой на момент добавления | Историческая правда, не live-каталог |

					CREATE MATERIALIZED VIEW daily_revenue AS
SELECT date_trunc('day', created_at) AS day, SUM(total_cents) AS revenue
FROM orders WHERE status = 'paid'
GROUP BY 1;
-- REFRESH MATERIALIZED VIEW CONCURRENTLY daily_revenue;
				

Зафиксируйте source of truth и invalidation: triggers, async workers или периодический refresh. Eventual consistency подходит для дашбордов; для ledger balances — только с явными правилами.

На интервью: если просят ускорить read-heavy ленту, предложите денормализацию с конкретной стратегией sync и назовите, что может быть stale.

Типовые ошибки: денормализация до замера стоимости join; нет плана backfill при изменении источника; дублирующие кэши без ownership; денормализация вместо недостающих индексов.

Компромисс — между производительностью чтения и простотой запросов с одной стороны и сложностью update / риском устаревших данных с другой: денормализуйте только когда нормализованные join или агрегаты с доказательствами не укладываются в бюджет латентности или доступности.

Чеклист:

• Определите медленный read path и целевую латентность.
• Назовите канонический source of truth.
• Задайте sync: trigger, job или расписание refresh.
• Сформулируйте допустимую staleness для продукта.
• Спланируйте migration/backfill до переключения чтений.