> Как называется операция переноса данных из нескольких таблиц в одну для оптимизации запросов (Go)

Короткий ответ

Это денормализация - операция объединения данных из нескольких таблиц в одну (или добавление избыточных колонок) для ускорения чтения за счёт уменьшения числа JOIN. В Go-бэкенде часто реализуется через миграции (например, golang-migrate) или ETL-процессы. Цель - пожертвовать согласованностью и местом на диске ради производительности на чтение. Альтернативный термин - материализация, если речь о предвычисленном представлении.

Подробное объяснение

Денормализация - это осознанное нарушение нормальных форм (обычно 3NF) для оптимизации запросов. В реляционных базах JOIN - дорогая операция, особенно при больших объёмах данных и множественных связях. Денормализация устраняет необходимость в JOIN на этапе чтения, перенося стоимость объединения на этап записи или фоновые процессы.

В контексте Go-бэкенда это особенно актуально: Go-сервисы часто работают с PostgreSQL или MySQL, где планировщик может строить неоптимальные планы при глубоких JOIN-цепочках. Денормализация бывает:

• Полная - создание новой таблицы со всеми нужными полями из нескольких источников.
• Частичная - добавление избыточных колонок в существующую таблицу (например, user_name в таблицу заказов).
• Материализованные представления - предвычисленные агрегаты, обновляемые по расписанию или триггерам.

Ключевой trade-off: выигрыш на чтении против сложности поддержки согласованности. При обновлении исходных данных нужно синхронно обновлять денормализованные копии - либо в той же транзакции, либо через eventual consistency (например, через message queue в Go-сервисе).

На практике

В Go-проектах денормализация применяется в нескольких сценариях:

1. CQRS-подход - отдельные read models, которые заполняются из событий. Go-сервис пишет в нормализованную модель, а read model обновляется асинхронно через consumer.
2. Кэширование в БД - таблица-кэш с денормализованными данными, которая пересоздаётся по расписанию (например, через cron внутри Go-приложения).
3. Гибридный подход - денормализованные колонки для горячих запросов, при этом исходные таблицы остаются источником истины.

Важно: в Go-коде денормализация обычно не видна на уровне бизнес-логики - она скрыта в репозиториях. Репозиторий для чтения работает с денормализованной таблицей, репозиторий для записи - с нормализованной. Это требует аккуратного проектирования интерфейсов, чтобы не смешивать модели.

Пример кода

Пример денормализации через миграцию в Go-проекте (golang-migrate):

SQL
-- миграция: создание денормализованной таблицы для списка заказов
CREATE TABLE order_list (
    order_id      BIGINT PRIMARY KEY,
    user_name     TEXT NOT NULL,      -- из users
    product_title TEXT NOT NULL,      -- из products
    total_amount  NUMERIC(10,2) NOT NULL,
    created_at    TIMESTAMPTZ NOT NULL
);

-- заполнение из нормализованных таблиц
INSERT INTO order_list (order_id, user_name, product_title, total_amount, created_at)
SELECT o.id, u.name, p.title, o.amount, o.created_at
FROM orders o
JOIN users u ON u.id = o.user_id
JOIN products p ON p.id = o.product_id;

В Go-коде репозиторий для чтения:

GO
type OrderListRepository struct {
    db *sql.DB
}

func (r *OrderListRepository) GetRecentOrders(ctx context.Context, limit int) ([]OrderListItem, error) {
    rows, err := r.db.QueryContext(ctx, `
        SELECT order_id, user_name, product_title, total_amount, created_at
        FROM order_list
        ORDER BY created_at DESC
        LIMIT $1`, limit)
    // обработка ошибок и сканирование
}

Как отвечать на собеседовании

Начните с точного термина - денормализация. Затем сразу покажите понимание trade-off: скорость чтения против сложности записи и согласованности. Упомяните, что в Go-бэкенде это часто реализуется через отдельные read models или материализованные представления. Приведите конкретный пример из практики: например, лента заказов с именем пользователя и названием товара - вместо трёх JOIN делаем один SELECT из готовой таблицы.

Если спросят про альтернативы - назовите индексы, покрывающие индексы, кэширование в Redis, но подчеркните, что денормализация - это структурное решение на уровне схемы БД, а не временное кэширование. Также упомяните, что в Go-проектах важно разделять write path и read path, чтобы денормализация не протекала в бизнес-логику.

Что проверяет интервьюер

Интервьюер оценивает:

• Знание терминологии и понимание, чем денормализация отличается от нормализации.
• Умение видеть trade-off: не просто "ускоряет запросы", а осознание цены - сложность поддержки, риск рассинхронизации.
• Практический опыт: как вы решали проблему медленных JOIN в реальном проекте.
• Понимание архитектурных паттернов: CQRS, event sourcing, материализованные представления.
• Способность объяснить, как это вписывается в Go-экосистему: миграции, репозитории, конкурентность при обновлении денормализованных данных.

Типичные ошибки

• Называть это "объединением таблиц" или "merge" - это неверно, merge - это операция слияния строк, а не структурная оптимизация.
• Не упоминать про согласованность - главный минус денормализации.
• Говорить, что денормализация - это всегда плохо или всегда хорошо. Нет, это инструмент с конкретной ценой.
• Путать с индексами: индексы ускоряют поиск в существующей структуре, денормализация меняет структуру.
• Не упоминать, что в Go-проектах денормализация часто реализуется через отдельные read models, а не через изменение исходных таблиц.
• Предлагать денормализацию как первое решение - интервьюер ждёт, что вы сначала рассмотрите индексы, оптимизацию запросов, только потом структурные изменения.