Denormalizacja to celowe wprowadzenie redundancji do schematu bazy danych — świadomie duplikujesz albo doklejasz dane, które w „czystym” modelu siedziałyby w osobnej tabeli, żeby przyspieszyć odczyty. To nie jest bałagan ani błąd początkującego: to projektowa decyzja, którą podejmujesz po tym, jak schemat jest już porządnie znormalizowany, a profiler pokazuje, że konkretne zapytania duszą się na JOIN-ach.
Mechanizm jest prosty. Normalizacja rozbija dane na wiele wąskich tabel, żeby każdy fakt był zapisany dokładnie raz — świetne dla spójności i zapisów, ale każdy odczyt wymaga sklejania tych tabel z powrotem. Denormalizacja idzie w drugą stronę: trzymasz powtórzone wartości tam, gdzie są potrzebne, żeby baza nie musiała ich za każdym razem liczyć ani łączyć. Płacisz za to pamięcią i tym, że przy zmianie danych musisz zaktualizować kilka miejsc naraz. Klasyczny trade-off: szybsze SELECT-y kosztem wolniejszych i bardziej ryzykownych INSERT/UPDATE.
Przykład z praktyki
Masz tabele orders i order_items, a na dashboardzie ciągle pokazujesz sumę zamówienia. Zamiast za każdym razem robić SUM po pozycjach, dokładasz kolumnę total_amount bezpośrednio do orders:
ALTER TABLE orders ADD COLUMN total_amount DECIMAL(10,2);
Teraz lista zamówień to zwykły odczyt jednej tabeli, bez agregacji. Wadą jest to, że gdy ktoś zmieni cenę pozycji, musisz pamiętać o przeliczeniu total_amount — zwykle robi się to triggerem albo w warstwie aplikacji. Podobnie działają liczniki w stylu comments_count na poście (żeby nie zliczać komentarzy przy każdym wyświetleniu) albo skopiowana nazwa kategorii obok category_id.
Częste błędy i mity
- Denormalizacja na zapas. Najpierw normalizuj i zmierz. Jeśli zapytanie jest szybkie, redundancja to tylko dług, który ktoś kiedyś spłaci w postaci niespójnych danych.
- Mylenie z brakiem normalizacji. Denormalizujesz świadomie schemat, który umiesz znormalizować. Bałagan z przypadku to nie to samo.
- Zapominanie o synchronizacji. Zduplikowane dane potrafią się rozjechać. Bez triggerów, transakcji albo procesu odświeżania prędzej czy później
total_amountprzestanie się zgadzać z pozycjami. - „NoSQL nie wymaga normalizacji”. W bazach dokumentowych denormalizacja bywa wręcz domyślna, ale problem spójności duplikatów nie znika — po prostu spada na Ciebie.
Pojęcia powiązane: normalizacja i postaci normalne (1NF, 2NF, 3NF), redundancja danych, materialized view (zmaterializowany widok jako kontrolowana forma denormalizacji), indeksy, cache, anomalie aktualizacji oraz trade-off odczyt kontra zapis.