Перейти на PRO

Что такое денормализация в базах данных?

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

Ответ

Денормализация — это намеренное внесение избыточности данных в схему базы данных путем нарушения нормальных форм. Цель — оптимизация производительности операций чтения (запросов) за счет уменьшения количества JOIN-операций, что особенно важно для read-heavy и аналитических систем (OLAP).

Пример:

Нормализованная схема:

CREATE TABLE Customers (
    customer_id INT PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(100)
);

CREATE TABLE Orders (
    order_id INT PRIMARY KEY,
    customer_id INT REFERENCES Customers(customer_id),
    total DECIMAL(10,2)
);

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

CREATE TABLE Orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    customer_name VARCHAR(100), -- Дублируем данные из Customers
    customer_email VARCHAR(100), -- Дублируем данные из Customers
    total DECIMAL(10,2)
);

Преимущества:

  • Ускорение запросов: Устраняются дорогостоящие JOIN между таблицами.
  • Упрощение запросов: Сложные выборки становятся проще для написания и понимания.
  • Повышение производительности отчетов: Идеально для систем, где скорость чтения критична.

Недостатки и риски:

  • Аномалии данных: Риск несогласованности при обновлении (например, изменение email в одном месте, но не в другом).
  • Увеличение объема хранилища: Из-за дублирования данных.
  • Усложнение операций обновления (UPDATE/INSERT/DELETE): Требуется обновлять данные в нескольких местах, что может быть медленнее и сложнее.

Когда применять: В хранилищах данных (Data Warehouses), системах бизнес-аналитики (BI), кэшированных представлениях (материализованных представлениях) и других сценариях, ориентированных на анализ, а не на транзакции.

Ответ 18+ 🔞

Да ты посмотри, что эти умники выдумали! Денормализация, блядь. Ну, в рот меня чих-пых, звучит-то как — будто что-то сломали. Так оно и есть, по сути.

Вот представь: есть у тебя идеальный, блядь, порядок. Всё по полочкам, как учили в институте. Клиенты отдельно, заказы отдельно. Красота, нихуя не дублируется. Это и есть нормализация, священная корова всех джунов.

CREATE TABLE Customers (
    customer_id INT PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(100)
);

CREATE TABLE Orders (
    order_id INT PRIMARY KEY,
    customer_id INT REFERENCES Customers(customer_id),
    total DECIMAL(10,2)
);

А теперь приходит суровый продакт и говорит: "Мне нужно, чтобы отчёт по заказам за последние пять лет строился за секунду, а не за пять минут, пока ты там свои JOIN'ы хуяришь". И вот тут начинается магия, блядь. Берёшь эту красоту и сознательно её ломаешь. Называется — денормализация.

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

CREATE TABLE Orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    customer_name VARCHAR(100), -- Смотри-ка, а имя клиента уже тут! С какого хуя?
    customer_email VARCHAR(100), -- И почта его тут же, блядь! Дублируем, сука!
    total DECIMAL(10,2)
);

И что мы, блядь, выигрываем?

  • Скорость, ёпта! Запросы летают, потому что JOIN'ов нихуя нет. Прочитал одну таблицу — и у тебя уже всё есть.
  • Простота. Запросы пишутся в две строки, даже стажёр не запутается.
  • Для отчётов — просто песня. Когда читать нужно овердохуища раз, а писать — раз в неделю.

Но, а теперь, сука, ложка дёгтя размером с бульдозер:

  • Аномалии, блядь! Это главная жопа. Поменял клиент свою почту? А в старых заказах-то она осталась старая! Полная несогласованность, пиздец. Теперь у тебя один и тот же чел в системе с тремя разными мылами.
  • Место жрёт. Данные дублируются — хранилище пухнет. Но сейчас диски дешёвые, так что похуй, обычно.
  • Обновлять — ад. Хуякнуть новую запись — это теперь не просто в Orders вставить, а надо везде, где этот клиент задублирован, данные проверить и подтянуть. Геморрой.

Так когда же эту, блядь, денормализацию применять? Да когда читать надо часто и много, а писать — редко. Различные хранилища данных (Data Warehouses), эти ваши системы аналитики, материализованные представления — вот их родная стихия. Там где скорость отчёта важнее, чем идеальная согласованность каждой строчки в реальном времени.

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

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