У навчальних курсах нормалізація подається як абсолютне благо. Третя нормальна форма - це мета, до якої треба прагнути. Досвідчені розробники знають, що це не так просто, але все одно часто нормалізують більше, ніж потрібно - бо так правильно за підручником.
Що відбувається на практиці
Коли таблиця розбита на шість пов'язаних сутностей заради теоретичної чистоти, кожен читаючий запит перетворюється на ланцюжок JOIN-ів. При невеликих обсягах це непомітно. При мільйонах рядків і десятках одночасних з'єднань - це вже інша розмова. Планувальник запитів PostgreSQL чи MySQL не завжди обирає оптимальний план для складних JOIN-ів, особливо коли статистика таблиць застаріла.
Погляд початківця проти погляду практика
Початківець нормалізує, бо так вчили. Досвідчений нормалізує, бо це виглядає архітектурно грамотно. Але грамотна архітектура - та, що відповідає реальним патернам читання і запису, а не та, що добре виглядає на діаграмі.
- Денормалізація виправдана, коли читання переважає над записом у співвідношенні більшому за 8 до 1
- Матеріалізовані представлення - компроміс між цілісністю і швидкодією
- Дублювання окремих полів іноді дешевше, ніж додатковий JOIN
Рішення про нормалізацію треба приймати на основі профілю навантаження, а не на основі того, як виглядає схема.