MySQL + SQL · Lesson 30

Database Design में Denormalization

Denormalization क्या है

Denormalization पढ़ना तेज़ बनाने को tables में कुछ redundant data जानबूझकर वापस जोड़ना है। यह normalization का उल्टा है। जहाँ normalization duplication हटाने को data बाँटता है, denormalization बड़े, read-heavy databases पर धीमे joins बचाने को थोड़ी duplication स्वीकारता है।

💡 Normalization correctness को redundancy हटाता है; denormalization speed को कुछ वापस जोड़ता है।

Denormalize क्यों

पूरी तरह normalized database हर तथ्य एक बार store करता है, पर इसे पढ़ने को अक्सर कई tables में joins चाहिए, जो data बड़ा होने पर धीमे हो सकते हैं। Denormalization कुछ data साथ store करता है ताकि queries इसे सीधे पढ़ सकें, joins बिना। लक्ष्य तेज़ reads हैं।

एक सरल उदाहरण

Normalized: orders table सिर्फ़ customer_id store करती है, और name पाने को आप customers से join करते हैं:

orders(id, customer_id)  JOIN  customers(id, name)

Denormalized: orders table customer का name भी सीधे store करती है:

orders(id, customer_id, customer_name)

अब order को उसके customer name के साथ पढ़ने को कोई join नहीं चाहिए — पर name हर order में duplicate है।

Trade-off

तेज़ reads — आम queries को joins नहीं चाहिए।
ज़्यादा storage — duplicated data अतिरिक्त जगह लेता है।
Inconsistency का ख़तरा — अगर customer का name बदले, हर copy update करनी होगी।

आप update सरलता और storage को read speed से बदलते हैं। यह तभी फ़ायदेमंद जब reads writes से बहुत ज़्यादा हों।

Normalization बनाम denormalization

बात	Normalization	Denormalization
लक्ष्य	Redundancy हटाना	Reads तेज़ करना
Redundancy	न्यूनतम	कुछ, जानबूझकर
Joins	ज़्यादा चाहिए	कम चाहिए
Updates	सरल, सुरक्षित	Copies sync करनी
किसके लिए	Correctness, writes	Read-heavy performance

कब इस्तेमाल करें

Reads writes से बहुत ज़्यादा हों — जैसे reporting या analytics।
Normalized design मापने योग्य रूप से बहुत धीमा हो।
आप duplicated data manage कर सकें और copies sync रख सकें।

ज़्यादातर applications को, normalized शुरू कीजिए। Denormalize चुनकर, सिर्फ़ जहाँ यह साफ़ performance में मदद करे।

आम गलतियाँ

बहुत जल्दी denormalize करना। Normalized शुरू कीजिए; ज़रूरत पड़ने पर ही optimise।
Copies sync करना भूलना। Duplicated data हर जगह update होना चाहिए।
Write-heavy tables denormalize करना। यह reads को मदद करता है, बार-बार writes को नहीं।
इसे ख़राब design से मिलाना। Denormalization जानबूझकर है, अनजाने redundancy नहीं।

सारांश

Denormalization तेज़ reads को कुछ redundancy वापस जोड़ता है।
यह data साथ store करके joins बचाता है, duplication की कीमत पर।
Trade-off read speed बनाम storage और update complexity है।
इसे सिर्फ़ तब इस्तेमाल कीजिए जब reads हावी हों और normalization बहुत धीमा हो।
Normalized शुरू कीजिए; optimisation के रूप में चुनकर denormalize।

आगे, उल्टा दोहराइए normalization में, या हल किए steps देखिए normalization examples में।

अक्सर पूछे जाने वाले प्रश्न (FAQ)

Denormalization क्या है?

Denormalization पढ़ना तेज़ बनाने को tables में कुछ redundant data जानबूझकर वापस जोड़ना है। यह normalization का उल्टा है: आप महँगे joins बचाने को कुछ duplicate data स्वीकारते हैं, आमतौर पर बड़े, read-heavy databases पर queries तेज़ करने को।

आप database denormalize क्यों करेंगे?

आप read performance सुधारने को denormalize करते हैं। Normalized data को अक्सर कई tables में joins चाहिए, जो धीमे हो सकते हैं। कुछ data साथ store करके (भले duplicate), queries तेज़ चलती हैं क्योंकि वे उन joins से बचती हैं।

Normalization और denormalization में क्या अंतर है?

Normalization data को संबंधित tables में बाँटकर redundancy हटाता है, जो consistency और updates को बढ़िया है। Denormalization तेज़ reads को कुछ redundancy वापस जोड़ता है। एक correctness optimise करता है, दूसरा speed।

Denormalization के नुक़सान क्या हैं?

मुख्य नुक़सान duplicate data, ज़्यादा storage, और inconsistency का ख़तरा हैं — अगर वही तथ्य दो बार store हो, एक copy update करके दूसरा न करना errors कराता है। आपको उन updates को सावधानी से manage करना होगा।

मुझे कब denormalize करना चाहिए?

Denormalize सिर्फ़ तब जब normalized design reads को मापने योग्य रूप से बहुत धीमा हो, और reads writes से बहुत ज़्यादा हों। ज़्यादातर applications को, normalized design सही default है; denormalize performance optimisation के रूप में चुनकर।