Перейти на PRO

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

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

Ответ

Денормализация — это осознанный процесс добавления избыточных (дублирующихся) данных в базу данных для оптимизации скорости выполнения запросов. По сути, это контролируемое нарушение правил нормализации ради производительности.

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

Пример: дублирование данных для ускорения запросов

Представим, что нам нужно часто отображать имя автора вместе с его комментариями.

Нормализованная схема (требует JOIN):

-- Таблица пользователей
CREATE TABLE Users (
    user_id INT PRIMARY KEY,
    user_name VARCHAR(100)
);

-- Таблица комментариев
CREATE TABLE Comments (
    comment_id INT PRIMARY KEY,
    text TEXT,
    author_id INT, -- Внешний ключ
    FOREIGN KEY (author_id) REFERENCES Users(user_id)
);

-- Запрос для получения комментария с именем автора
SELECT c.text, u.user_name FROM Comments c JOIN Users u ON c.author_id = u.user_id;

Денормализованная схема (без JOIN):

Мы дублируем user_name прямо в таблицу Comments.

CREATE TABLE Comments (
    comment_id INT PRIMARY KEY,
    text TEXT,
    author_id INT,
    author_name VARCHAR(100) -- Избыточное поле
);

-- Запрос становится проще и быстрее
SELECT text, author_name FROM Comments;

Когда следует применять денормализацию?

  • Для ускорения чтения (Read Performance): Когда количество операций чтения значительно превышает количество операций записи/обновления.
  • В аналитических системах (OLAP): Для построения отчетов и агрегации данных, где сложные JOIN'ы могут быть слишком медленными.
  • Для упрощения запросов: Когда логика соединения таблиц становится слишком сложной.

Риски и недостатки:

  • Аномалии данных: При обновлении данных (например, смене имени пользователя) нужно обновить их во всех местах, где они дублируются. Иначе возникнет несогласованность.
  • Усложнение записи (Write Complexity): Операции INSERT и UPDATE становятся более сложными и медленными.
  • Увеличение объема хранения: Дублирование данных требует больше дискового пространства.

Вывод: Денормализацию следует рассматривать как инструмент оптимизации, который применяется точечно после профилирования и выявления узких мест, а не как стандартный подход к проектированию.

Ответ 18+ 🔞

Ну вот смотри, как обычно бывает: сидишь ты, проектируешь свою идеальную, блядь, нормализованную базу, всё по Кодду, всё красиво. А потом приходит продакт и говорит: "А почему этот ебучий список комментариев грузится три секунды?". И тут начинается, ёпта, цирк.

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

Сценарий из жизни: надо имя автора рядом с комментами

Вот как это выглядит у хорошего, правильного мальчика:

Нормализованная схема (для идеалистов):

-- Таблица пользователей
CREATE TABLE Users (
    user_id INT PRIMARY KEY,
    user_name VARCHAR(100)
);

-- Таблица комментариев
CREATE TABLE Comments (
    comment_id INT PRIMARY KEY,
    text TEXT,
    author_id INT, -- Внешний ключ
    FOREIGN KEY (author_id) REFERENCES Users(user_id)
);

-- И вот этот ебальный запрос каждый раз
SELECT c.text, u.user_name FROM Comments c JOIN Users u ON c.author_id = u.user_id;

А теперь как делает суровый практик, у которого сервис уже лег от нагрузки:

Денормализованная схема (ради скорости, в пизду идеалы):

Просто тупо засунули author_name прямо в таблицу с комментами. Да, дубль. Да, избыточно. Зато быстро, блядь.

CREATE TABLE Comments (
    comment_id INT PRIMARY KEY,
    text TEXT,
    author_id INT,
    author_name VARCHAR(100) -- Вот он, наш грешок. Лежит тут, как ни в чём не бывало.
);

-- А запрос превращается в конфетку
SELECT text, author_name FROM Comments;

Так когда же, блядь, стоит на это идти?

  • Когда читают, как сумасшедшие, а пишут редко (Read-Heavy). Типичная история для ленты новостей или каталога.
  • В этих ваших аналитических хранилищах (OLAP). Там запросы такие, что десять JOIN'ов — это ещё легко, и каждый нихуя не торопится.
  • Когда запросы становятся настолько запутанными, что проще выстрелить себе в колено.

Но не обольщайся, подвохи есть, и они охуенные:

  • Аномалии данных, ёбта. Решил пользователь сменить ник с "КотЭ_Любимый" на "ПитО_Грозный". Поздравляю, теперь тебе надо этот ник обновить не в одной записи, а в тысячах комментариев. Пропустишь один — и сидит уже "КотЭ_Лёбимый" под постом про собак. Пиздец и несогласованность.
  • Запись становится медленнее и сложнее. Раньше обновил имя в одном месте — и все счастливы. Теперь надо хуярить update по всей таблице комментариев.
  • Места жрёт больше. Дубли, они же не бесплатные. Диск — не резиновый, хотя сейчас это часто не главная проблема.

Итог, блядь: Денормализация — это не "как надо проектировать с нуля". Это инструмент для оптимизации, который ты вытаскиваешь, когда всё уже горит и профилировщик показывает, что эти ебучие джойны — узкое горлышко. Сначала нормализуй, потом меряй, и только если реально не летит — тогда уже, сматывая удочки, дублируй данные. И да пребудет с тобой сила и согласованность, хоть иногда и ценой идеальной схемы.

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