2010-07-06 13 views
32

मैंने देखा है कि यहां बहुत से लोग एक टेबल में 20+ (मैंने 55 के रूप में देखा है) कॉलम के साथ तालिकाओं का हवाला देते हैं। अब मैं डेटाबेस डिज़ाइन विशेषज्ञ होने का नाटक करता हूं, लेकिन मैंने हमेशा सुना है कि यह एक भयानक अभ्यास है। जब मैं इसे देखता हूं, तो मैं आमतौर पर एक से एक रिश्ते के साथ दो तालिकाओं में विभाजित करने का सुझाव देता हूं: जिसमें सबसे अधिक उपयोग किया जाने वाला डेटा होता है, दूसरा कम से कम उपयोग किया जाने वाला डेटा होता है। हालांकि एक ही समय में प्रदर्शन का संभावित मुद्दा (कम जॉइन और ऐसे) हैं। तो मेरा सवाल यह है:कितने कॉलम बहुत अधिक कॉलम हैं?

जब वास्तव में बड़े पैमाने पर डेटाबेस की बात आती है, तो वास्तव में बड़ी मात्रा में कॉलम होने का लाभ होता है, इस तथ्य के बावजूद कि यह आमतौर पर कई नल मूल्यों की ओर जाता है?

जो अधिक प्रदर्शन हिट है: बहुत से कॉलम के साथ बहुत सारे कॉलम, या बहुत कम कॉलम के साथ कम कॉलम?

+0

बहुत स्पष्ट लगता है कि यह पूरी तरह से डेटाबेस की आवश्यकताओं पर निर्भर करता है और प्रत्येक संबंधित ऑपरेशन कितना भारी होता है। उत्तर के लिए धन्यवाद। –

उत्तर

39

तालिका का डिज़ाइन उस इकाई पर निर्भर करता है जिसकी उसे स्टोर करने की आवश्यकता है। यदि सभी डेटा एक साथ हैं, तो 50 कॉलम (या यहां तक ​​कि 100) करने के लिए सही काम हो सकता है।

तब तक तालिका normalized है, डेटाबेस क्षमताओं के अलावा, अनुकूलित करने की आवश्यकता के अलावा आकार के बारे में अंगूठे का कोई नियम नहीं है।

3

मैं ओडेड से सहमत हूं। मैंने उनमें 500 कॉलम के साथ तालिकाओं को देखा है, और उनमें से सभी कॉलम सही जगह पर थे। बस उन तथ्यों की संख्या पर विचार करें जो किसी रोजमर्रा की वस्तु के बारे में स्टोर करना चाहते हैं, और आप जल्द ही देखेंगे क्यों।

यदि यह उन सभी कॉलम का चयन करने के लिए असुविधाजनक साबित होता है, या निर्दिष्ट करने के लिए कि कौन से कॉलम चुनने के लिए चुनते हैं, तो आप केवल एक छोटे से अनुपात में रूचि रखते हैं, तो आपको एक दृश्य को परिभाषित करने के लिए उपयुक्त लग सकता है।

0

जो एक प्रदर्शन हिट का अधिक है: मिलती है बहुत से NULLs के बहुत सारे के साथ स्तंभों की बहुत सारे, या कम कॉलम?

यह पूरी तरह से आपके द्वारा संग्रहीत डेटा, इंडेक्स और आपके द्वारा किए जाने वाले डेटा पर निर्भर करता है। कोई भी आपको यह सुनिश्चित नहीं कर सकता है कि आप जो भी स्टोर कर रहे हैं उसे जानने के बिना किसी दूसरे से बेहतर काम करता है। आम तौर पर सामान्यीकरण नियम अलग-अलग तालिकाओं और उपयोगकर्ता FKeys को अलग-अलग डेटा "बल" देंगे यदि आपके पास बड़ी तालिका है लेकिन मैं असहमत हूं कि यह हमेशा एक बड़ी तालिका से बेहतर प्रदर्शन करता है। आप दर्जनों प्रश्नों में 6-7 स्तरों के साथ जुड़ सकते हैं जो कभी-कभी त्रुटियों का कारण बनते हैं क्योंकि सरल प्रश्नों में बड़ी क्वेरी में त्रुटि उत्पन्न करने की संभावना अधिक होती है।

यदि आप जो कुछ भी कर रहे हैं उसकी कुछ आवश्यकताएं पोस्ट करते हैं तो हम आपको डीबी को सही तरीके से डिजाइन करने में मदद कर सकते हैं।

1

ओडीबीसी की 8000 की एक वर्ण सीमा है .... इसलिए यह एक भौतिक सीमा है जिसके अतिरिक्त चीजें बेहद निराशाजनक होती हैं।

मैंने एक टेबल पर काम किया जिसमें 138 कॉलम थे .. यह बहुत ही लिखा गया था और इसे सामान्यीकृत किया जा सकता था। यद्यपि यह डेटाबेस किसी के निर्माण का प्रतीत होता है कि डेटाबेस डिज़ाइन में सम्मेलन क्यों हैं और एक बार में सभी का परीक्षण करने का निर्णय लेते हैं।

डेटा वेयरहाउसिंग और रिपोर्टिंग सर्वर में पहुंचने पर बहुत व्यापक फ़्लैटेड टेबल होने पर काफी आम है। वे बहुत तेज़ हैं और इसका मतलब है कि आपको प्रदर्शन के लिए रैम में अपना डेटाबेस एंटरली स्टोर नहीं करना है।

4

कितने कॉलम बहुत अधिक कॉलम हैं?

जब आपको लगता है कि यह अब समझ में आता है या कोई अन्य कॉलम जोड़ने का अधिकार है।

आम तौर पर आवेदन पर निर्भर करता है।

1

मेरे अनुभव के अनुसार, इसमें कम शामिल होना बेहतर होता है क्योंकि वे अक्सर बड़े डेटाबेस में होते हैं। जब तक आपकी डेटाबेस टेबल को एकल इकाई (छात्र, शिक्षक और अन्य) स्टोर करने के लिए डिज़ाइन किया गया है, यह ठीक होना चाहिए। ताकि यह बाद में आपके कोड में एक ऑब्जेक्ट के रूप में प्रदर्शित किया जाएगा। इसलिए, यदि आप इकाई को कई तालिकाओं में विभाजित करते हैं तो आपको बाद में अपनी ऑब्जेक्ट भरने के लिए कई जोड़ों का उपयोग करना होगा। इसके अलावा यदि आप अपनी डेटा एक्सेस लेयर (जैसे कि नेट में लिंक) उत्पन्न करने के लिए ओआरएम का उपयोग करते हैं, तो प्रत्येक तालिका के लिए अलग-अलग कक्षाएं उत्पन्न होती हैं (बेशक उनके बीच एक रिश्ते के साथ) और इसका उपयोग करना मुश्किल होगा।

एक और बात यह है कि आप निर्दिष्ट कर सकते हैं कि कौन से कॉलम आपकी क्वेरी में वापस आते हैं और इससे आपके आवेदन में पारित डेटा को कम कर दिया जाएगा, लेकिन यदि आपको किसी अन्य तालिका से भी एक कॉलम की आवश्यकता है तो आपको शामिल होना होगा। और ज्यादातर मामलों में आपके पास इतने सारे कॉलम हैं, तो डीबी में संग्रहीत बड़ी मात्रा में डेटा होने की संभावना अधिक है। इसलिए यह शामिल होने से एनयूएलएल की तुलना में अधिक नुकसान होगा।

प्रत्येक परियोजना जिस पर मैंने काम किया है वह अलग है इसलिए आपको प्रत्येक कहानी के लिए संतुलन मिलना चाहिए।

+0

बहुत सच है। जाहिर है, जुड़ता है और कई चुनिंदा प्रश्न धीमे होते हैं, इसलिए सुझाव दिया गया है कि निरंतरता को तोड़ने के बिना जहां भी संभव हो, denormalization पर विचार किया जाना चाहिए। – JCasso

0

यह भी आपकी तालिका के उपयोग के लिए निर्भर करता है। यदि आप इसे पढ़ने के लिए अनुकूलित करना चाहते हैं तो यह एक टेबल में सभी को एक साथ रखना एक अच्छा विचार हो सकता है।

नो-एसक्यूएल दुनिया में (उदाहरण के लिए कैसंड्रा/हबेस) कॉलम की संख्या पर कोई बाधा नहीं है और इसे वास्तव में कई कॉलम रखने के लिए एक अच्छा अभ्यास माना जाता है। यह भी संग्रहीत तरीके से आता है (कोई अंतराल नहीं)। जांच करते समय मूल्यवान।

-4

यह एक बेहतर तालिका का उपयोग करना बेहतर है जहां आप पूछताछ करते समय जुड़ने का उपयोग करने से बच सकते हैं, यह निर्भर करता है कि कॉलम एक ही इकाई या अलग इकाई के हैं या नहीं।

उदाहरण के लिए, मान लें कि आप कार्य प्रवाह के लिए डेटाबेस डिज़ाइन कर रहे हैं जहां कुछ फ़ील्ड जूनियर श्रमिकों द्वारा संपादित किए जाएंगे, और वरिष्ठ श्रमिकों द्वारा कुछ फ़ील्ड। इस मामले में सभी स्तंभों को एक ही तालिका में रखना बेहतर होता है।

+3

-1: _why_ क्या यह बेहतर है? _ किस तरह से यह बेहतर है? –

0

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

साथ ही, इसमें शामिल होने से बचने के लिए कई स्तंभों को घुमाने के संबंध में, मुझे लगता है कि जोड़ों से बचने से प्रदर्शन लाभ इंडेक्स रखरखाव के माध्यम से खो जाता है, दोनों पढ़ने और लिखने का एक सामान्य वर्कलोड माना जाता है। पढ़ने के प्रदर्शन के लिए फ़ील्ड पर इंडेक्स जोड़ना उन क्षेत्रों को अपनी तालिका में स्थानांतरित करने की आवश्यकता का संकेत हो सकता है।

संबंधित मुद्दे