В каких случаях стоит денормализовать базу данных?
Что проверяют
Умеете ли вы осознанно нарушать правила. Нормализация это база, а денормализация решение с ценой, и от вас ждут понимания этой цены.
Как отвечать
Начните с того, что денормализация это сознательное дублирование данных ради скорости чтения. Применяют её, когда измерения показали проблему, а не заранее.
Ситуации, где она оправдана:
- тяжёлые соединения в горячем запросе: список, который открывают тысячи раз в минуту, собирается из пяти таблиц. Часть полей копируют в основную таблицу;
- счётчики и агрегаты: число комментариев, сумма заказа, рейтинг. Пересчитывать их запросом на каждый показ дороже, чем хранить и обновлять;
- аналитика и отчёты: витрины и широкие таблицы, где чтение важнее компактности, а данные обновляются пакетно;
- исторические снимки: в позиции заказа сохраняют цену и название товара на момент покупки. Это не оптимизация, а требование предметной области: цена в справочнике потом изменится;
- кеширующие таблицы и материализованные представления, когда согласованность допускает отставание.
Обязательно назовите цену: данные придётся поддерживать в согласии в нескольких местах, появляются аномалии при частичном обновлении, растёт объём и стоимость записи. Отсюда практики: обновлять копии в одной транзакции или триггером, иметь фоновую сверку, документировать источник истины, а для агрегатов рассмотреть материализованное представление с регулярным обновлением.
Где спотыкаются
Денормализуют до первых замеров и получают сложность без выигрыша.
Забывают про обновление копий, и через месяц отчёты расходятся с исходными таблицами.
Путают денормализацию с отсутствием нормализации: сначала нормальная модель, потом осознанные исключения.