के साथ मुख्य तालिका मैं सोच रहा था कि डेटाबेस डिजाइन करने के लिए कौन सा दृष्टिकोण बेहतर है?सैकड़ों बनाम कुछ छोटे
मेरे पास वर्तमान में एक बड़ी तालिका (प्रति पंक्ति 9 7 कॉलम) है जहां लुकअप टेबल के संदर्भ के साथ मैं कर सकता हूं।
क्या कुछ स्तंभों को छोटे तालिकाओं में समूहित करने के लिए प्रदर्शन के लिए बेहतर नहीं होगा और उन्हें एक संपूर्ण पंक्ति का संदर्भ देने के लिए महत्वपूर्ण कॉलम जोड़ें?
यदि आप अपनी तालिका को कई हिस्सों में विभाजित करते हैं, तो आपको एक ही पंक्ति के लिए अपने सभी कॉलम प्राप्त करने के लिए अतिरिक्त जुड़ने की आवश्यकता होगी - इससे आपको समय लगेगा।
97 कॉलम बहुत ज्यादा नहीं, वास्तव में है - मैं 100
यह सब कैसे अपने डेटा का उपयोग किया जा रहा है पर निर्भर करता है परे रास्ता देखा है - अगर आपकी पंक्ति सिर्फ 97 कॉलम, सम्पूर्ण, और आवश्यकताएं 97 कॉलम तक - तो यह वास्तव में कभी भी उन्हें विभिन्न तालिकाओं में विभाजित करने के लिए समझ में आता है।
यह मतलब हो सकता है यदि:
आप कुछ "बड़ी" कॉलम (जैसे XML, VARCHAR(MAX) आदि) एक अलग तालिका में, अगर आप उन सब समय की जरूरत नहीं है स्थानांतरित कर सकते हैं -> उस स्थिति में, आपकी "मूल" पंक्ति छोटी हो जाती है और आपकी मूल तालिका बेहतर प्रदर्शन करेगी - जब तक आपको उन अतिरिक्त बड़े कॉलम
की आवश्यकता नहीं है, तो आप कुछ कॉलम को एक अलग तालिका में ले जा सकते हैं जो नहीं हैं हमेशा उपस्थित, उदाहरण के लिए कॉलम जो "वैकल्पिक" हो सकते हैं और केवल उदाहरण के लिए उपस्थित हो सकते हैं पंक्तियों का 20% - उस स्थिति में, आप अपने शेष 80% मामलों के लिए कुछ प्रसंस्करण बचा सकते हैं जहां उन कॉलम की आवश्यकता नहीं है।
+1: और कॉलम जैसे: टिप्पणी 1, टिप्पणी 2, टिप्पणी 3 ... – JeffO
@marc_s ऐसा लगता है कि SQL सर्वर बेहतर संचालन संचालन पर टेक्स्ट-आधारित मानों की बजाय इन्ट्स? –
@AdrianK .: SQL सर्वर संचालन को बेहतर करता है, डेटा प्रकार जितना छोटा होता है, और चर-लंबाई के ऊपर निश्चित लंबाई वाले प्रकार (जैसे INT) को पसंद करता है क्योंकि निश्चित-लंबाई वाले प्रकारों में कम ओवरहेड होता है। –
प्रासंगिक कॉलम को विभिन्न तालिकाओं में समूहित करना बेहतर होगा। यह आपके डेटाबेस के प्रदर्शन के साथ-साथ प्रोग्रामर के रूप में उपयोग की आसानी में सुधार करेगा। आपको पहले अपने कॉलम के बीच सभी अलग-अलग रिश्तों को खोजने का प्रयास करना चाहिए और इसके बाद आपको इन रिश्तों को ध्यान में रखते हुए सभी चीजों को तोड़ने का प्रयास करना चाहिए (प्राथमिक कुंजी, फोर्किंग कुंजी, संदर्भ और आगे का उपयोग करना)। आरेख बनाने के लिए प्रयास करें यह http://www.simple-talk.com/iwritefor/articlefiles/354-image008.gif और इसे वहां से ले जाएं।
जरूरी नहीं है! एक ही पंक्ति में कई "भागों" होने के अतिरिक्त अतिरिक्त जॉइन का अर्थ है, और वे "मुक्त" नहीं हैं - इसमें तालिकाओं में शामिल होने के लिए समय लगता है! –
@marc_s हाँ, लेकिन जब आप एक सेल के लिए 97 कोल्स के साथ एक टेबल से पूछताछ कर रहे हैं तो यह एक छोटी सी टेबल के लिए बेहतर है। इसके अलावा संगठनात्मक उद्देश्यों के लिए यह और अधिक समझ में आता है। (निश्चित रूप से डेटा के आधार पर ..यदि डेटा सभी 97 कोलों पर प्रासंगिक है तो इसे इस तरह से रखें लेकिन मुझे संदेह है कि) –
जब तक आपका डेटा denormalized नहीं है, तो सभी कॉलम एक ही तालिका में रखने की संभावना है। SQL सर्वर अलग-अलग तालिकाओं से बफर पूल में पृष्ठों को पढ़ता है। इस प्रकार आपके पास प्रत्येक एक्सेस पर शामिल होने की लागत होगी, भले ही पृष्ठों का उपयोग पहले से ही बफर पूल में हो। यदि आप किसी कुंजी के साथ प्रति क्वेरी डेटा की केवल कुछ पंक्तियों तक पहुंचते हैं तो एक अनुक्रमणिका उसी क्वेरी में सभी कॉलम के साथ उस क्वेरी को ठीक करेगी। यहां तक कि यदि आप पंक्तियों का एक बड़ा प्रतिशत स्कैन करेंगे (> बड़ी तालिका का 1%) लेकिन केवल 97 कॉलम में से कुछ आप कॉलम को उसी तालिका में रखने से बेहतर हैं क्योंकि आप एक गैर क्लस्टर इंडेक्स का उपयोग कर सकते हैं जो कवर करता है पूछताछ। हालांकि, यदि डेटा को भारी रूप से असामान्य किया जाता है तो इसे सामान्यीकृत किया जाता है, जो परिभाषा द्वारा इसे सामान्यता के नियमों के आधार पर कई तालिकाओं में विभाजित करता है, जिसके परिणामस्वरूप अनावश्यकता समाप्त हो जाती है, जिसके परिणामस्वरूप बेहतर प्रदर्शन होगा और आप केवल विशिष्ट डेटा तक पहुंचने के लिए प्रश्न लिखने में सक्षम होंगे तत्वों की आपको आवश्यकता है।
** [यहां देखें] (http://stackoverflow.com/a/10931849/1425057) ** –