Ответ
Денормализация — это сознательное отступление от правил нормализации БД путем введения избыточности данных или объединения таблиц. Цель — оптимизация производительности операций чтения (SELECT) за счет усложнения операций обновления (INSERT, UPDATE, DELETE) и потенциального риска нарушения целостности данных.
Когда это оправдано?
- Системы OLAP (аналитика и отчетность): Сложные запросы с множеством
JOINвыполняются медленно. Предварительно рассчитанные и денормализованные данные ускоряют генерацию отчетов в разы. - Высоконагруженные read-heavy сервисы: Например, лента новостей или каталог товаров, где скорость отклика критична.
- Упрощение сложных запросов: Избавление от многоуровневых
JOINделает запросы проще для написания и понимания.
Пример: Нормализованная схема для интернет-магазина:
-- Таблицы Orders и Customers связаны по CustomerId
SELECT o.OrderId, o.Date, c.Name, c.City
FROM Orders o
JOIN Customers c ON o.CustomerId = c.CustomerId
WHERE o.Date > '2024-01-01';
Денормализованный вариант (добавляем избыточные поля в Orders):
ALTER TABLE Orders ADD CustomerName NVARCHAR(100), CustomerCity NVARCHAR(100);
-- Теперь запрос выполняется без JOIN
SELECT OrderId, Date, CustomerName, CustomerCity
FROM Orders
WHERE Date > '2024-01-01'; -- Гораздо быстрее
Преимущества:
- Высокая скорость чтения (меньше
JOIN, меньше обращений к диску). - Упрощение запросов и схемы БД для потребителей данных (например, для BI-систем).
Недостатки и риски:
- Аномалии обновления: Если имя клиента (
CustomerName) изменится в основной таблицеCustomers, его нужно будет обновить во всех связанных заказах вOrders. Это требует сложных триггеров или процедур. - Повышенные затраты на хранение (избыточные данные).
- Усложнение логики модификации данных.
Вывод: Денормализация — это компромисс. Ее применяют осознанно, взвешивая выгоду от ускорения чтения против затрат на поддержание целостности, обычно в сценариях, где данные изменяются редко (например, архивные или аналитические данные).