Normalisering organiserer data, så hvert faktum lever præcis ét sted, hvilket fjerner redundans. Denormalisering duplikerer bevidst data for at gøre læsninger hurtigere. De fleste skemaer starter normaliserede og denormaliseres kun der, hvor målinger kræver det.
Hver tabel beskriver én entitet; relaterede data refereres via foreign key.
-- Normalized: a customer's city is stored once
customers(id, name, city_id)
cities(id, name)
orders(id, customer_id, total)
-- Denormalized: city copied onto every order for fast reporting
orders(id, customer_id, city_name, total)
-- + a summary table maintained by the app or triggers
order_daily_totals(day, city_name, total_sales)
Vælg normaliseret som default af hensyn til korrekthed. Denormalisér en specifik hot read-sti kun, efter EXPLAIN viser, at joins er flaskehalsen — og foretræk at holde kilden til sandheden normaliseret, mens du vedligeholder en afledt kopi (summary-tabel, materialiseret cache), du kan genopbygge.
Dette er en central afvejning i skemadesign: at overnormalisere får dashboards til at krybe, at overdenormalisere avler inkonsistente data, der er dyre at afstemme. At vide hvorfor du ville duplikere data — og hvordan du holder kopien troværdig — adskiller et skema, der skalerer, fra et, der rådner.
Et bibliotek af IT-interviewspørgsmål med detaljerede svar — fra Junior til Senior.
Donér