4.4.22 · Coding › Databases
Intuition Ek sentence mein core idea
Normalization data ko bahut saari choti, non-redundant tables mein split karta hai taaki writes safe rahein (koi contradiction nahi). Lekin har read ko phir JOINs ke saath data re-assemble karna padta hai, jo time leta hai. Denormalization ek deliberate kaam hai jisme controlled redundancy wapas add ki jaati hai taaki reads fast ho jaayein , aur ye accept kiya jaata hai ki writes mushkil ho jaayenge (copies ko sync rakhna padega).
Cost ko read path se write path par shift karo — tabhi worth it hai jab reads writes se kaafi zyada hon.
Definition Denormalization
Denormalization ek process hai jisme ek normalized schema mein jaanbujhkar redundancy introduce ki jaati hai — columns duplicate karke, pre-computed aggregates store karke, ya tables merge karke — taaki read performance improve ho, lekin iske badle mein write complexity aur storage badhti hai.
Key word: jaanbujhkar (intentional) . Ek schema jo kabhi normalize hi nahi hua woh bas bura design hai. Denormalization ek conscious optimization hai jo ek already-normalized schema par apply ki jaati hai.
Intuition Redundancy normally buri kyun hoti hai — aur yahan hum ise tolerate kyun karte hain
Redundancy khatarnak hoti hai kyunki ek hi fact do jagah rehta hai, isliye dono disagree kar sakte hain (update anomaly). Normalization ise har fact ko exactly ek jagah rakh ke remove karti hai.
Denormalization kehti hai: "Main ye khatre ko accept karta hoon, lekin main iske khilaaf guard karoonga (triggers, app logic, periodic refresh) kyunki speed gain iske laayak hai ."
Chalo pehle principles se sochte hain, rules yaad karne ki jagah.
Maano ek query ko n tables mein spread data chahiye. Unhe combine karne ke liye database joins perform karta hai. Do tables R aur S ka nested-loop join bina indexes ke roughly O ( R ⋅ S ) rows examine karta hai, ya S par index hone par O ( R log S ) . n tables ko chain karna is kaam ko multiply kar deta hai.
Intuition Inequality ko samajhna (Feynman check)
Left side ka read/write ratio right side ke cost ratio se zyada hona chahiye. Agar tum writes se 1000× zyada read karte ho, toh expensive sync bhi (C sy n c bada ho) theek hai. Agar writes frequent hain, toh sync cost badhti jaati hai aur denormalization haarne lagti hai.
Definition Char standard denormalization moves
Pre-joined / merged tables — parent table ke columns child mein store karo taaki join gayab ho jaaye (jaise orders mein seedha customer_name rakh do).
Derived / pre-computed columns — koi aggregate store karo jo otherwise SUM/COUNT maangta (jaise order_total, comment_count).
Repeating / array columns — ek alag junction table ki jagah list inline store karo (jaise tags array).
Materialized views — ek expensive query ka cached result , schedule ya trigger par refresh hota hai.
Worked example Example 1 —
order_total store karna
Normalized: orders, order_items(order_id, price, qty). Total dikhane ke liye har baar ye run karo
total = ∑ i ( p r i c e i × q t y i )
Denormalized: orders.total_amount add karo, ek baar compute karke store karo.
Step
Ye step kyun?
Hot read identify karo
Order summary page hazaron baar/din load hota hai
Rare write identify karo
Items sirf checkout par change hoti hain (ek baar)
f r / f w bahut bada
Inequality strongly satisfy hoti hai → denormalize karo
total_amount add karo
Har read par SUM join hata deta hai
order_items par trigger add karo
total_amount ko sahi rakhta hai → redundancy guard karta hai
Worked example Example 2 — Blog
comment_count
Normalized: har page render par SELECT COUNT(*) FROM comments WHERE post_id = ?.
Bura kyun? 1M comments wala viral post har page view par 1M rows scan karwa deta hai.
Denormalized: posts.comment_count, insert par increment, delete par decrement.
Ye step (increment) kyun? Ek simple arithmetic update O ( 1 ) hai vs O ( N ) count — humne cost ko rare write par shift kar diya.
Worked example Example 3 — Denormalize kab NAHI karna chahiye
Ek banking ledger jahan balances kabhi disagree nahi karne chahiye aur writes frequent hain. Yahan C sy n c high hai (transactional aur exact hona chahiye) aur f w f r ke comparable hai. Inequality fail hoti hai → normalized raho ; balance ko single source of truth se compute karo.
Common mistake "Denormalization hamesha DB ko faster banata hai."
Ye sahi kyun lagta hai: joins hatana obviously reads ko speed deta hai, toh lagta hai free win hai.
Fix: ye reads ko fast karta hai lekin writes slow karta hai aur storage bloat karta hai , aur data drift ka risk bhi hai. Write-heavy system par ye net loss hai. Hamesha check karo f r / f w > C sy n c / C j o in .
Common mistake "Main pehle denormalize kar loonga safe rehne ke liye."
Ye sahi kyun lagta hai: "performance ke liye pehle design karo."
Fix: Pehle normalize karo, baad mein evidence ke saath denormalize karo . Premature denormalization bugs (sync logic) laata hai pehle hi, jab tum jaante bhi nahi ki kaun sa query slow hai. Measure karo, hot read dhundo, tab duplicate karo.
Common mistake "Duplicated column apne aap sahi rehega."
Ye sahi kyun lagta hai: tumne ek baar set kiya aur testing mein theek laga.
Fix: redundancy enforce karni padti hai — triggers, transactions, app-layer invariants, ya scheduled refresh. Guard nahi kiye gaye duplicates drift karenge aur update anomalies produce karenge.
Common mistake Never-normalized schema ko denormalization samajhna.
Ye sahi kyun lagta hai: dono mein redundancy hai.
Fix: denormalization ek normalized design ki deliberate optimization hai; buri redundancy bas ek absent design step hai.
Recall Quick self-test (chhupaao aur jawaab do)
Denormalization kya trade karta hai, aur kis direction mein?
Denormalize karne ki inequality batao.
Teen denormalization techniques bolo.
Duplicated data ko "guard" kyun karna zaroori hai?
Ek aisa case bolo jahan nahi karna chahiye denormalize.
Recall Feynman: 12 saal ke bachche ko samjhao
Socho tumhara toy box super tidy hai: cars ek box mein, wheels doosre mein, stickers teesre mein (ye normalized hai — kuch repeat nahi hota). Lekin har baar jab tum finished car se khelna chahte ho, tumhe teen boxes mein bhaagna padta hai aur assemble karna padta hai — slow! Toh tum kuch fully-built cars shelf par ready rakhte ho (ye denormalized hai — copies, jaldi grab ho jaati hain). Pakad: agar tum asli cars ko repaint karo, toh shelf copies bhi repaint karna yaad rakhna padega, nahi toh woh galat dikhenge. Tum ready-made copies sirf unhi toys ki rakhte ho jinse tum hamesha khelte ho, unki nahi jo tum mushkil se use karte ho.
Mnemonic Trade yaad rakhne ke liye
"READ fast, WRITE last." Read ing quick banane ke liye denormalize karo; tum iske liye baad mein pay karte ho, har write par (sync cost). Aur: D-R-Y hai code ke liye, W-E-T hai hot reads ke liye (Write Everything Twice jab reads dominate karein).
Normalization (1NF 2NF 3NF BCNF) — jise hum partially undo kar rahe hain
Update Insert Delete Anomalies — woh khatre jo denormalization wapas laati hai
Indexing — reads speed karne ka alternative tarika, data duplicate kiye bina
Materialized Views — denormalization ki cached-query form
Database Triggers — duplicates sync rakhne ka common mechanism
OLTP vs OLAP — OLAP/warehouses (star schema) design se heavily denormalized hote hain
CAP Theorem — distributed systems aksar cross-node joins avoid karne ke liye denormalize karte hain
Denormalization kya hai? Ek normalized schema mein deliberately controlled redundancy add karna taaki reads fast ho jaayein, write complexity aur storage ki keemat par.
Denormalize karne par kaun sa path sasta hota hai aur kaun sa mehenga? Reads saste ho jaate hain (kam joins); writes mehengi ho jaati hain (duplicates sync mein rakhne padte hain).
Denormalize kab karna chahiye — rule batao. Jab f r / f w > C sy n c / C j o in ho — read/write ratio sync-to-join cost ratio se zyada ho.
Char denormalization techniques bolo. Pre-joined/merged tables, pre-computed derived columns, inline repeating/array columns, materialized views.
Never-normalized schema denormalization se alag kyun hai? Denormalization ek already-normalized design ki deliberate optimization hai; un-normalized schema bas ek missing design step hai.
Denormalization kaun sa khatraa wapas laati hai aur isse kaise guard karein? Update anomalies / data drift; triggers, transactions, app-layer invariants, ya scheduled refresh se guard karo.
Ek aisa case batao jahan denormalize nahi karna chahiye. Write-heavy, correctness-critical systems (jaise financial ledger) jahan f w high ho aur sync exact hona zaroori ho.
Normalization reads kyun slow karta hai? Data bahut saari tables mein split hota hai, isliye reads ko unhe JOIN karke wapas jodhna padta hai, aur join cost table sizes aur tables ki sankhya ke saath badhti hai.
Reads speed karne ke liye denormalization ka sasta alternative kya hai? Proper indexing — ye reads speed karta hai bina data duplicate kiye ya drift ka risk liye.
Small non-redundant tables
Triggers, app logic, refresh
Delta = fr*Cjoin - fw*Csync
Pre-joined tables, aggregates