Перейти на PRO

В каких случаях и для чего применяется денормализация базы данных?

Тип вопроса: Базы данных Вероятность: 10% Категория: Golang Разработчик

Ответ

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

Основная идея — пожертвовать скоростью записи и усложнить логику обновления ради того, чтобы избежать дорогостоящих JOIN-операций при чтении.

Ключевые примеры:

  1. Аналитика и отчетность: Для построения сложных отчетов часто требуются данные из множества таблиц. Создание отдельной денормализованной таблицы (витрины данных) значительно ускоряет агрегирующие запросы.

    -- Вместо JOIN'ов таблиц products, orders, order_items
CREATE TABLE monthly_sales_report (
    product_id INT,
    product_name VARCHAR(255), -- Дублированные данные
    month DATE,
    total_quantity_sold INT,
    total_revenue DECIMAL(12, 2)
);

  2. Кэширование вычисляемых значений: Хранение часто запрашиваемых агрегатов прямо в основной таблице, чтобы не вычислять их каждый раз.

    • Количество комментариев к посту: Вместо COUNT(*) при каждом запросе. 
      ALTER TABLE posts ADD COLUMN comments_count INT DEFAULT 0;
    • Рейтинг товара: Вместо вычисления среднего по всем отзывам.

  3. Высоконагруженные системы: В лентах новостей или логах действий часто дублируют информацию (например, имя и аватар пользователя) рядом с его действием, чтобы не делать JOIN для каждого из сотен элементов на странице.

Минусы, о которых нужно помнить:

  • Избыточность данных: Увеличивается размер БД.
  • Риск аномалий: Данные могут стать несогласованными, если логика обновления не отработала корректно (например, имя пользователя изменилось, а в старых записях ленты осталось прежним).
  • Усложнение логики записи: При обновлении данных нужно не забыть обновить все их дубликаты.

Главное правило: Денормализацию применяют, когда количество операций чтения значительно превышает количество операций записи (reads >> writes).

Ответ 18+ 🔞

Ну, слушай, вот есть такая штука — денормализация. Это когда ты специально начинаешь пихать в базу одни и те же данные по пять раз, как последний распиздяй. А зачем, спросишь? Да чтобы потом, блядь, не ебаться с этими бесконечными JOIN-ами, когда читаешь!

Представь: у тебя там таблички, всё по науке, красиво, нормализовано. А потом приходит запрос на отчёт, и тебе нужно сджойнить пол-базы, чтобы получить одну цифру. И система начинает тупить, как пьяный сантехник в понедельник. Вот тут-то и приходит осознание: "А похуй на целостность, лишь бы быстро работало!". И ты начинаешь дублировать всё, что шевелится.

Ключевые примеры, чтобы было понятно:

  1. Аналитика и отчёты (просто пиздец какой-то): Вместо того чтобы каждый раз склеивать products, orders и order_items, ты заранее создаёшь отдельную, жирную, денормализованную таблицу-витрину. Туда скидываешь всё, что нужно для отчёта, и потом просто SELECT * FROM monthly_sales_report, не паришься.

    -- Вместо JOIN'ов таблиц products, orders, order_items
CREATE TABLE monthly_sales_report (
    product_id INT,
    product_name VARCHAR(255), -- Дублированные данные, да похуй!
    month DATE,
    total_quantity_sold INT,
    total_revenue DECIMAL(12, 2)
);

  2. Кэширование прямо в таблице (хитрая жопа): Чтобы не считать одно и то же по сто раз. Например, количество комментов к посту. Вместо того чтобы каждый раз делать COUNT(*) и насиловать базу, ты просто добавляешь столбец comments_count и обновляешь его, когда кто-то пишет или удаляет коммент. Гениально и просто, как тапок.

  3. Высоконагруженные системы (там, где читают овердохуища раз): Лента новостей, например. Ты что, будешь для каждого поста джойнить таблицу пользователей, чтобы достать его имя и аватарку? Да хуй там! Ты сразу эти данные засунешь в запись о посте. Пусть лежат. Зато отдашь ленту за милисекунды.

Но, блядь, не всё так радужно, есть и подводные ебучки:

  • База раздувается, как питон, съевший кролика. Данных становится в разы больше.
  • Может возникнуть пиздец с целостностью. Обновил пользователь имя, а в старых постах в ленте осталось старое. Нужно писать хитрую логику обновления, а это — дополнительный геморрой.
  • Писать становится сложнее. Раньше обновил в одном месте — и всё. А теперь нужно побежать и поправить все копии этих данных, разбросанные по разным таблицам. Один раз забудешь — и привет, аномалии.

Так когда же это применять? Да тогда, когда ты чётко понимаешь: запросов на чтение — просто пиздец сколько, а записей — раз в сто меньше. reads >> writes, как говорят умные дяди. Вот тогда можно и нужно идти на эту тёмную сторону. А так — живи в нормализованном мире, пока он тебя не заебёт.

© ХакСобесов, 2026
support@hacksobesov.com