Что такое денормализация базы данных и когда её применяют?

Давай разберём эту тему, а то у меня от одних этих слов «денормализация» уже волнение ебать начинается. Представь, что ты построил идеальный, красивый склад. Каждая коробка на своём месте, ничего лишнего, всё по полочкам. Это нормализованная база. Красиво, чисто, но когда тебе срочно нужна какая-то херня из пяти разных коробок, ты начинаешь бегать по всему складу и собирать её по кусочкам. А время-то идёт, запросы виснут, и пользователи уже готовы тебя сожрать.

Вот денормализация — это когда ты, ёпта, смотришь на этот бардак с JOIN-ами и говоришь: «Да похуй, я лучше продублирую эти данные в одном месте, зато доставать буду в разы быстрее». Жертвуешь идеальной чистотой ради скорости, как гоночный болид, который жрёт бензина дохуя, но летит.

Типичный пример, чтобы не быть голословным:

Вот смотри, как это выглядит в коде. Сначала всё по правилам, для перфекционистов:

-- НОРМАЛИЗОВАННАЯ СХЕМА (3NF)
CREATE TABLE users (
    id INT PRIMARY KEY,
    username VARCHAR(50)
);

CREATE TABLE orders (
    id INT PRIMARY KEY,
    user_id INT REFERENCES users(id),
    total_amount DECIMAL(10,2),
    created_at TIMESTAMP
);

-- Чтобы получить отчёт "Имя пользователя + сумма его заказа", нужен JOIN:
SELECT u.username, o.total_amount, o.created_at
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.created_at > '2023-01-01';

А теперь включаем режим «прагматик» и делаем так, чтобы не скакать между таблицами:

-- ДЕНОРМАЛИЗОВАННАЯ СХЕМА
-- Добавляем избыточное поле username прямо в таблицу orders
CREATE TABLE orders (
    id INT PRIMARY KEY,
    user_id INT,
    username VARCHAR(50), -- Дублируем данные из users
    total_amount DECIMAL(10,2),
    created_at TIMESTAMP
);

-- Теперь тот же отчёт выполняется без JOIN, что может быть в разы быстрее:
SELECT username, total_amount, created_at
FROM orders
WHERE created_at > '2023-01-01';

Видишь разницу? В первом случае ты каждый раз таскаешься в таблицу users за именем. Во втором — имя уже лежит в заказе, берёшь и готово. Скорость выборки взлетает просто до небес, особенно если записей овердохуища.

Но, чувак, тут не всё так просто. Это палка о двух концах, и второй конец может больно ударить.

Главная проблема — несогласованность. Допустим, юзер VasyaPupkin передумал и стал VasyaCool. В таблице users мы его поменяли, а в тысячах его старых заказов в поле username так и останется VasyaPupkin. И в отчёте будет разнобой. Доверия к таким данным, ебать, ноль.

Как с этим жить? Варианты есть:

1. Асинхронные обновления. Меняем имя в users, кидаем событие в очередь, и фоновый процесс тихонько пробегается по всем связанным заказам и обновляет username. Не мгновенно, но хоть как-то.
2. Смириться. Если бизнесу похуй, что в исторических отчётах старое имя — значит, так и живём. Это называется eventual consistency, когда данные «со временем» становятся согласованными. Или не становятся.
3. Денормализовать только то, что не меняется. Например, дату рождения или город рождения пользователя. А логин, который может поменяться, — лучше не дублировать.

Где это реально нужно применять?

• Аналитические штуки (OLAP). Там данные обновляются раз в сутки, зато читают их постоянно и сложными запросами. Тут денормализация — святое дело.
• Высоконагруженные читающие системы. Соцсети, ленты новостей. Там каждая миллисекунда на счету, и JOIN из пяти таблиц просто убьёт производительность.
• Микросервисы. Чтобы не дергать по сети другой сервис за каждой мелочью, можно продублировать у себя кусочек его данных. Да, они могут устареть, зато твой сервис не ляжет, если соседний накрылся медным тазом.

Короче, денормализация — это как мощный допинг. Применяешь точечно, с умом, понимая все риски, и получаешь взрывную производительность на чтении. Начинаешь лить её на всё подряд — получаешь бардак в данных, от которого потом волосы дыбом встанут. Э, бошка, думай, прежде чем дублировать!