असली दुनिया में सामान्यीकरण
डाटाबेस सामान्यीकरण अनुप्रयोग विकास की पवित्र गायों में से एक है। प्रत्येक स्नातक प्रोग्रामिंग कोर्स जिसे आपने लिया है या बुक किया है, संभवतः डेटाबेस को सामान्य करने के महत्व का प्रचार करता है ।
यह उस सत्यवाद को चुनौती देने का समय है। कभी-कभी अपने डेटाबेस को denormalize करना ठीक है!
आपको सामान्य कब करना चाहिए?
डेटाबेस सामान्यीकरण आपके डेटा की अखंडता की सुरक्षा करता है। यह कई मामलों में एक अच्छा विचार है, और आपको दिमाग में सामान्यीकरण के साथ किसी भी डेटाबेस डिजाइन प्रयास शुरू करना चाहिए। यदि आप अपने डेटाबेस को सामान्य कर सकते हैं, तो इसके लिए जाओ! वास्तव में, इस साइट पर अपने डेटाबेस को सामान्य करने के तरीके पर कुछ व्यावहारिक सलाह दी गई है:
- अपने सामान्य डेटाबेस को पहले सामान्य रूप में रखना (1 एनएफ)
- दूसरे सामान्य फॉर्म (2 एनएफ) में अपना डाटाबेस डालना
- तीसरे सामान्य फॉर्म (2 एनएफ) में अपना डाटाबेस डालना
निचली पंक्ति यह है कि आपको अपने डेटाबेस को सामान्य बनाना चाहिए जब तक कि आपके पास ऐसा करने का कोई अच्छा कारण न हो। सामान्यीकरण आमतौर पर ध्वनि डिजाइन अभ्यास है। यह अनावश्यक जानकारी को कम करता है, प्रदर्शन को अनुकूलित करता है और आपके डेटाबेस के विभिन्न कोनों में समान डेटा रखने के परिणामस्वरूप डेटा अखंडता के मुद्दों की संभावना कम कर देता है।
सामान्य करने के लिए कुछ अच्छे कारण नहीं हैं
उस ने कहा, आपके डेटाबेस को सामान्यीकृत न करने के कुछ अच्छे कारण हैं। आइए कुछ देखें:
- जॉइन महंगा हैं । आपके डेटाबेस को सामान्यीकृत करने में अक्सर कई टेबल बनाना शामिल होता है। असल में, आप आसानी से हवादार हो सकते हैं जो आपको लगता है कि एक साधारण क्वेरी होना चाहिए जो पांच या 10 टेबल फैलता है। यदि आपने कभी भी पांच-टेबल में शामिल होने का प्रयास किया है, तो आप जानते हैं कि यह सिद्धांत रूप से काम करता है, लेकिन यह अभ्यास में दर्दनाक रूप से धीमा है। यदि आप एक वेब एप्लिकेशन बना रहे हैं जो बड़ी तालिकाओं के खिलाफ एकाधिक-जुड़ने वाले प्रश्नों पर निर्भर करता है, तो आप खुद को सोच सकते हैं, "अगर केवल यह डेटाबेस सामान्य नहीं था!" जब आप अपने सिर में यह विचार सुनते हैं, तो यह एक अच्छा समय है denormalizing पर विचार करें। यदि आप उस क्वेरी द्वारा उपयोग किए गए सभी डेटा को एक ही टेबल में चिपका सकते हैं, तो वास्तव में आपके डेटा अखंडता को खतरे में डालकर, इसके लिए जाएं! एक विद्रोही बनें और अपने डेटाबेस को denormalize। आप वापस नहीं देखेंगे!
- सामान्य डिजाइन मुश्किल है । यदि आप जटिल डेटाबेस स्कीमा के साथ काम कर रहे हैं, तो आप शायद सामान्यीकरण की जटिलता पर टेबल के खिलाफ अपने सिर को टक्कर दे पाएंगे। अंगूठे के एक साधारण नियम के रूप में, यदि आप पूरे दिन खर्च कर रहे हैं कि चौथे सामान्य रूप में कैसे स्थानांतरित किया जाए, तो आप सामान्यीकरण को बहुत दूर ले जा रहे हैं। वापस कदम और खुद से पूछें कि क्या यह वास्तव में जारी रखने लायक है।
- त्वरित और गंदे जल्दी और गंदे होना चाहिए । यदि आप सिर्फ प्रोटोटाइप विकसित कर रहे हैं, तो बस जो कुछ भी जल्दी से काम करता है। वास्तव में। यह ठीक है। सुरुचिपूर्ण डिजाइन की तुलना में रैपिड एप्लिकेशन विकास कभी-कभी अधिक महत्वपूर्ण होता है। प्रोटोटाइप चरण से आगे बढ़ने के लिए तैयार होने के बाद बस वापस जाएं और अपने डिज़ाइन पर सावधानीपूर्वक नज़र डालें। एक त्वरित और गंदे डेटाबेस डिज़ाइन के लिए आप जिस कीमत का भुगतान करते हैं वह यह है कि आपको इसे फेंकने की आवश्यकता हो सकती है और उत्पादन के लिए समय होने पर इसे शुरू करना पड़ सकता है।
- यदि आप नोएसक्यूएल डेटाबेस का उपयोग कर रहे हैं , पारंपरिक सामान्यीकरण वांछनीय नहीं है। इसके बजाय, BASE मॉडल का उपयोग करके अपना डेटाबेस डिज़ाइन करें जो बहुत अधिक क्षमाशील है। यह तब उपयोगी होता है जब आप अनियंत्रित डेटा जैसे ईमेल, छवियों या वीडियो संग्रहीत कर रहे हों।
सावधानी के कुछ शब्द
डाटाबेस सामान्यीकरण आमतौर पर एक अच्छा विचार है। ऐसा करने के लिए उचित लगता है जब आपको सामान्यीकरण के सिद्धांतों का पालन करने का प्रयास करना चाहिए। लेकिन यदि सभी संकेतक सामान्यीकरण को लागू करने के लिए बहुत जटिल होते हैं, तो ऐसे दृष्टिकोण पर विचार करें जो अभी भी आपके डेटा की सुरक्षा करते समय काम करेगा।
अंत में - यदि आप सामान्यीकरण के नियमों से भटकना चुनते हैं, तो आप डेटाबेस अखंडता को कैसे लागू करते हैं, इसके बारे में अतिरिक्त सतर्क रहें। यदि आप अनावश्यक जानकारी संग्रहीत करते हैं, तो यह सुनिश्चित करने के लिए कि ट्रिगर और अन्य नियंत्रण रखें, यह सुनिश्चित करने के लिए कि जानकारी सुसंगत रहे।