डेटाबेस को सामान्य करने से संसाधन प्रभाव क्या है?

Question

अपेक्षाकृत गैर-सामान्यीकृत फॉर्म से डेटाबेस लेते समय और इसे सामान्यीकृत करते समय, संसाधन उपयोग में बदल सकता है?

उदाहरण के लिए, सामान्यीकरण का अर्थ है कि अधिकतर टेबल कम से कम बनाए जाते हैं जिसका अर्थ है कि डेटाबेस में अब बड़ी संख्या में टेबल हैं, लेकिन उनमें से कई काफी छोटे हैं, जिससे अक्सर उपयोग किए जाने वाले लोगों को स्मृति में बेहतर फिट करने की अनुमति मिलती है।

तालिकाओं की उच्च संख्या का भी अर्थ है कि समेकित डेटा को प्राप्त करने के लिए अधिक शामिल होने की संभावना है (संभावित रूप से), इसलिए किसी को सिस्टम की उच्च संख्या में शामिल होने की अपेक्षा की जाती है।

तो, संसाधन उपयोग (यानी क्या बदल जाएगा) पर असर एक सामान्यीकृत डेटाबेस को सामान्यीकृत करता है?

---

संपादित करें: संदर्भ का एक सा जोड़ने के लिए, मैं एक मौजूदा 300 से अधिक भयानक तालिकाओं के साथ डेटाबेस है (यानी विरासत।)। डेटा का लगभग 1/2 टेक्स्ट है और दूसरा आधा या तो चार फ़ील्ड या पूर्णांक है। किसी भी प्रकार की कोई बाधा नहीं है। कारण मैं पूछता हूं कि मुख्य रूप से दूसरों को विश्वास दिलाने के लिए अधिक जानकारी प्राप्त करना है कि चीजों को बदलने की जरूरत है और प्रदर्शन या रखरखाव में कमी नहीं होगी। दुर्भाग्यवश, मुझे सामान्य रूप से जितना संभव हो सके सामान्यीकरण से बचने के लिए डी-सामान्यीकृत डेटाबेस के प्रदर्शन लाभों के बारे में पर्याप्त जानकारी प्राप्त करना है।

Answer 1

इसका वास्तव में सामान्य तरीके से उत्तर नहीं दिया जा सकता है, क्योंकि प्रभाव में डेटाबेस के विनिर्देशों और इसका उपयोग करने वाले ऐप्स के आधार पर प्रभाव भारी भिन्न होगा।

तो तुम मूल रूप से प्रभाव के विषय में सामान्य उम्मीदों ने कहा:

1. भंडारण के लिए कुल मिलाकर स्मृति मांगों को नीचे जाना चाहिए, के रूप में अनावश्यक डेटा हटा दिया जाता है
2. सीपीयू की जरूरत ऊपर जाना हो सकता है, पराक्रम प्रश्नों के रूप में अधिक महंगा हो (ध्यान दें कि कई मामलों में सामान्यीकृत डेटाबेस पर प्रश्न वास्तव में तेज़ होंगे, भले ही वे अधिक जटिल हों, क्योंकि क्वेरी इंजन के लिए अधिक अनुकूलन विकल्प हैं)
3. विकास संसाधन ई की जरूरत है ऊपर जाना हो सकता है, डेवलपर्स के रूप में सकता अधिक विस्तृत क्वेरी बनाने के तरीके की जरूरत (लेकिन दूसरी तरफ, आप डेटा अखंडता को बनाए रखने के लिए कम विकास के प्रयास की जरूरत है)

तो केवल वास्तविक जवाब हमेशा की तरह है : यह निर्भर करता है;)

नोट: यह मानता है कि हम सतर्क और जानबूझकर denormalization के बारे में बात कर रहे हैं। आप की बात कर रहे हैं अनुभवहीन डेवलपर्स के साथ आम के दृष्टिकोण रास्ता 'बस कुछ टेबल एक साथ के रूप में डेटा साथ आता है फेंक', मैं बयान है कि सामान्य सभी स्तरों पर संसाधन की जरूरत कम हो जाएगा जोखिम चाहते हैं;)

---

संपादित करें: विशिष्ट संदर्भ cdeszaq से जोड़ा संबंध में, मैं कहना चाहता हूँ 'गुड लक के माध्यम से अपनी बात हो रही है';)

oviously, टेबल्स और बगैर किसी अड़चन 300 से अधिक (के साथ), आपके सवाल का जवाब है! निश्चित रूप से 'सामान्यीकरण सभी स्तरों पर संसाधन आवश्यकताओं को कम करेगा' (और शायद बहुत महत्वपूर्ण), लेकिन:

इस तरह की गड़बड़ी पर प्रतिक्रिया करना एक प्रमुख उपक्रम होगा। यदि इस डेटाबेस का उपयोग कर केवल एक ऐप है, तो यह पहले से ही डरावना है - अगर बहुत सारे हैं, तो यह एक दुःस्वप्न बन सकता है!

तो यदि सामान्यीकरण लंबे समय तक संसाधनों की आवश्यकताओं को काफी कम करता है, तो परिस्थितियों के आधार पर परेशानी के लायक नहीं हो सकता है। यहां मुख्य प्रश्न दीर्घकालिक दायरे के बारे में हैं - यह डेटाबेस कितना महत्वपूर्ण है, इसका कितना समय उपयोग किया जाएगा, भविष्य में इसका उपयोग करने वाले अधिक ऐप्स होंगे, वर्तमान रखरखाव प्रयास निरंतर या बढ़ रहा है ...

उपेक्षा मत है कि यह एक चल प्रणाली है - भले ही यह बदसूरत और भयानक है, अपने विवरण यह (अभी तक) नहीं है ;-)

Answer 2

एक बात के लिए, आप परिणाम गणना करने के लिए समाप्त हो जाएगा। उदाहरण के लिए, यदि आप Post रों के एक नंबर के साथ एक Blog है,, आप या तो कर सकता है:

select count(*) from Post where BlogID = @BlogID 

जो की तुलना में

select PostCount from Blog where ID = @BlogID 

अधिक महंगा है और अगर आप, SELECT N+1 समस्या को जन्म दे सकता सावधान नहीं रहें।

बेशक दूसरे विकल्प के साथ आपको डेटा अखंडता को बनाए रखने के साथ सौदा करना है, लेकिन यदि पहला विकल्प पर्याप्त दर्दनाक है, तो आप इसे काम करते हैं।

सावधान रहें कि आप premature optimisation की गड़बड़ी न करें। इसे सामान्यीकृत फैशन में करें, फिर आवश्यकताओं के विरुद्ध प्रदर्शन को मापें, और केवल तभी कम हो जाए जब आप कमजोर दिखें।

Answer 3

आपके प्रश्न का एक बहुत ही सरल जवाब है: यह निर्भर करता है।

सबसे पहले, मैं आपके प्रश्न को 'denormalization का लाभ क्या है' के रूप में दोबारा वाक्यांश दूंगा, क्योंकि सामान्यीकरण कुछ ऐसा है जो डिफ़ॉल्ट के रूप में किया जाना चाहिए (शुद्ध तार्किक मॉडल के परिणामस्वरूप) और फिर denormalization कर सकते हैं बहुत विशिष्ट टेबल के लिए आवेदन किया जाना चाहिए जहां प्रदर्शन महत्वपूर्ण है। Denormalization की मुख्य समस्या यह है कि यह डेटा अखंडता प्रबंधन जटिल कर सकते हैं, लेकिन कुछ मामलों में लाभ जोखिम से अधिक है।

denormalization के लिए मेरी सलाह: केवल तभी होता है जब यह वास्तव में दर्द होता है और सुनिश्चित करता है कि जब आप किसी भी आवेषण, अद्यतन या हटाए जाने के बाद डेटा अखंडता को बनाए रखने की बात आती है तो आपको सभी परिदृश्य मिलते हैं।

Answer 4

टूट के अनुसार मैं, कि सामान्य पाया है में कुछ मामलों, प्रदर्शन में सुधार होगा।

छोटे टेबल अधिक तेज़ी से पढ़ते हैं। एक बुरी तरह से denormalized डेटाबेस अक्सर (ए) लंबी पंक्तियों और (बी) एक सामान्यीकृत डिजाइन की तुलना में अधिक पंक्तियों होगा।

कम छोटी पंक्तियों को पढ़ने से कम शारीरिक I/O का अर्थ है।

Answer 5

पूर्व पोस्टर्स द्वारा किए गए कुछ बिंदुओं को अंडरस्कोर करने के लिए: क्या आप वर्तमान स्कीमा वास्तव में denormalized है?उचित तरीके से (imho) एक डेटाबेस डिजाइन करने के लिए के लिए है:

• समझ लें,
• तब के रूप में सबसे अच्छा तुम प्रणाली/जानकारी मॉडल किए जाने वाले कर सकते हैं
• एक पूरी तरह से सामान्यीकृत मॉडल का निर्माण करता है, तो और आप के रूप में यह आवश्यक लगता है, एक नियंत्रित फैशन में denormalize प्रदर्शन को बढ़ाने की

(कुछ अन्य कारण denormalize हो सकता है, लेकिन केवल लोगों को मैं बंद हाथ के बारे में सोच सकते हैं राजनीतिक होते हैं - है मौजूदा कोड मैच के लिए, डेवलपर्स/प्रबंधकों, यह पसंद नहीं है आदि)

मेरे बिंदु है, अगर आप पूरी तरह से कभी सामान्यीकृत, आप एक denormalized डेटाबेस की जरूरत नहीं है, तो आप एक unnormalized मिल गया है एक। और मुझे लगता है कि यदि आप उन डेटाबेस के लिए कम विनम्र शर्तों के बारे में अधिक वर्णनात्मक सोच सकते हैं।

Answer 6

सामान्यीकृत स्कीमा INSERT/UPDATE/DELETE के लिए बेहतर प्रदर्शन करते हैं क्योंकि "अद्यतन विसंगतियों" नहीं हैं और वास्तविक परिवर्तन किए जाने की आवश्यकता है और अधिक स्थानीयकृत हैं।

चयन मिश्रित हैं। Denormalization अनिवार्य रूप से शामिल होने का भौतिककरण है। इसमें कोई संदेह नहीं है कि कभी-कभी शामिल होने में भौतिकरण अक्सर मदद करता है, हालांकि, भौतिकरण अक्सर बहुत निराशावादी होता है (शायद अधिक से अधिक नहीं), इसलिए यह न मानें कि denormalization आपकी मदद करेगा। इसके अलावा, सामान्यीकृत स्कीमा आम तौर पर छोटे होते हैं और इसलिए कम I/O की आवश्यकता हो सकती है। एक जुड़ाव जरूरी नहीं है, इसलिए स्वचालित रूप से यह न मानें कि यह होगा।

Answer 7

"सामान्यीकरण" लागू होता है केवल और विशेष रूपतार्किक एक डेटाबेस के डिजाइन करने के लिए।

डेटाबेस का लॉजिकल डिज़ाइन और डेटाबेस के भौतिक डिज़ाइन दो पूरी तरह से अलग चीजें हैं। डाटाबेस सिद्धांत हमेशा इस तरह से चीजों के लिए इरादा है। तथ्य यह है कि डेवलपर्स जो इस भेद को अनदेखा करते हैं/अनदेखा करते हैं (अज्ञानता से बाहर या लापरवाही से बाहर या आलसी से बाहर या किसी अन्य तथाकथित लेकिन अमान्य "कारण" से बाहर) विशाल बहुमत हैं, उन्हें सही नहीं बनाते हैं।

ए तार्किक डिज़ाइन सामान्यीकृत या नहीं कहा जा सकता है, लेकिन एक तार्किक डिज़ाइन स्वाभाविक रूप से किसी भी "प्रदर्शन विशेषता" को नहीं लेता है। बस 'सी: = सी + 1;' की तरह स्वाभाविक रूप से किसी भी प्रदर्शन विशेषता नहीं लेता है।

ए भौतिक डिज़ाइन "प्रदर्शन विशेषताओं" को निर्धारित करता है, लेकिन फिर एक भौतिक डिजाइन में "सामान्यीकृत या नहीं" होने की गुणवत्ता नहीं होती है।

"सामान्यीकरण को नुकसान पहुंचाने" की यह ग़लत धारणा वास्तव में ठोस सबूत से कुछ और नहीं है कि आज मौजूद सभी डीबीएमएस इंजन भौतिक डिजाइन विकल्पों में गंभीरता से कमी कर रहे हैं।

Answer 8

मैं Henrik Opel's #3 bullet point पर विस्तृत करना चाहता था। विकास लागत हो सकता है, लेकिन उन्हें नहीं करना है। वास्तव में, डेटाबेस के सामान्यीकरण को ओआरएम, कोड जनरेटर, रिपोर्ट राइटर्स इत्यादि जैसे उपकरणों के उपयोग को सरल बनाना या सक्षम करना चाहिए। ये टूल आपके अनुप्रयोगों की डेटा एक्सेस परत पर खर्च किए गए समय को काफी कम कर सकते हैं और व्यवसाय जोड़ने के लिए विकास को आगे बढ़ा सकते हैं मूल्य।

सामान्यीकृत डेटाबेस के विकास पहलू के बारे में आप एक अच्छी स्टैक ओवरफ्लो चर्चा here पा सकते हैं। इसके बारे में सोचने के लिए बहुत अच्छे उत्तर, टिप्पणियां और चीजें थीं।