Приведи пример, когда нормализация базы данных не нужна.

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

Типичный пример — аналитическое хранилище данных (Data Warehouse).

В операционной системе (OLTP) данные о заказах нормализованы: customers, orders, order_items, products. Для формирования отчёта о продажах с разбивкой по клиентам и продуктам потребуются сложные JOIN.

В хранилище для отчётов создают денормализованную таблицу sales_fact:

CREATE TABLE sales_fact (
    sale_date DATE NOT NULL,
    customer_id INT NOT NULL,
    customer_name VARCHAR(100) NOT NULL, -- Дублируется из customers
    product_id INT NOT NULL,
    product_name VARCHAR(100) NOT NULL,  -- Дублируется из products
    product_category VARCHAR(50) NOT NULL, -- Дублируется из products
    quantity INT NOT NULL,
    amount DECIMAL(10,2) NOT NULL,
    region VARCHAR(50) NOT NULL          -- Дублируется из customers
);

Почему это оправдано:

1. Скорость: Отчёты выполняются одним сканированием таблицы без JOIN.
2. Упрощение: Аналитикам не нужно знать сложную схему связей.
3. Контроль: Данные в хранилище обычно заполняются ETL-процессами (Extract, Transform, Load) из нормализованных источников, что гарантирует консистентность.

Другой пример — кэширование агрегированных данных (например, счётчик лайков у поста) прямо в записи поста для мгновенного отображения.