कोई प्राथमिक कुंजी के साथ सारणी

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

मैं सोच रहा हूं कि इस दृष्टिकोण के लिए प्रदर्शन प्रभाव क्या हैं। मैंने देखा है कि कुछ लोगों का सुझाव है कि तालिकाओं में एक क्लस्टरर्ड प्राथमिक कुंजी के रूप में स्वत: वृद्धि ("पहचान") int होना चाहिए, भले ही इसका कोई अर्थ न हो, क्योंकि इसका मतलब है कि डेटाबेस इंजन स्वयं उस मान का उपयोग जल्दी से कर सकता है एक बुकमार्क का उपयोग करने के बजाय एक पंक्ति देखें।

मेरा डेटाबेस सर्वर के समूह में विलय-दोहराया गया है, इसलिए मैंने पहचान int कॉलम से दूर झुका दिया है क्योंकि प्रतिकृति में सही होने के लिए वे थोड़ा बालों वाले हैं।

आपके क्या विचार हैं? क्या टेबल में प्राथमिक कुंजी होनी चाहिए? या क्या किसी भी क्लस्टर्ड इंडेक्स नहीं है अगर इस तरह से इंडेक्स करने के लिए कोई समझदार कॉलम नहीं है?

0
ro fr bn
चूंकि आप प्रतिकृति कर रहे हैं, इसलिए आपकी सही पहचान कुछ स्पष्ट है। मैं आपकी GUID को प्राथमिक कुंजी बनाउंगा लेकिन नॉनक्स्टस्टर क्योंकि आप newsequentialid का उपयोग नहीं कर सकते हैं। यह मुझे आपके सबसे अच्छे पाठ्यक्रम के रूप में चिपकता है। यदि आप इसे पीके नहीं बनाते हैं, लेकिन उस पर एक अनूठी अनुक्रमणिका डालते हैं, जल्दी या बाद में जो लोग सिस्टम को बनाए रख सकते हैं ताकि एफके रिश्तों को सही ढंग से बग पेश नहीं किया जा सके।
जोड़ा लेखक HLGEM, स्रोत

7 उत्तर

प्राथमिक कुंजी तीन उद्देश्यों को पूरा करती है:

  • इंगित करता है कि कॉलम अद्वितीय होना चाहिए
  • इंगित करता है कि कॉलम गैर-शून्य
  • होना चाहिए
  • इस उद्देश्य को दस्तावेज करें कि यह पंक्ति का अद्वितीय पहचानकर्ता है

पहले दो को कई तरीकों से निर्दिष्ट किया जा सकता है, जैसा कि आपने पहले से ही किया है।

तीसरा कारण अच्छा है:

  • मनुष्यों के लिए, ताकि वे आसानी से आपका इरादा देख सकें
  • कंप्यूटर के लिए, इसलिए एक प्रोग्राम जो आपकी तालिका की तुलना या अन्यथा संसाधित कर सकता है तालिका के प्राथमिक कुंजी के लिए डेटाबेस से क्वेरी कर सकता है।

एक प्राथमिक कुंजी को ऑटो-इंक्रिमेंटिंग नंबर फ़ील्ड नहीं होना चाहिए, इसलिए मैं कहूंगा कि प्राथमिक मार्गदर्शिका के रूप में अपना मार्गदर्शक कॉलम निर्दिष्ट करना एक अच्छा विचार है।

0
जोड़ा
@MattHamilton re "... प्राथमिक कुंजी के रूप में एक guid कॉलम रखने का अच्छा विचार नहीं है, क्योंकि प्राथमिक कुंजी क्लस्टर हैं और guids यादृच्छिक हैं" इसे दूर करने के लिए, आप SQL 2005/2008 पर "newsequentialid ()" फ़ंक्शन का उपयोग कर सकते हैं संपादित करें: अपेक्षित कोडिंग हॉरर पोस्ट जो इस बारे में बात करता है ;-)
जोड़ा लेखक Leon Bambrick, स्रोत
प्राथमिक कुंजी के रूप में एक guid कॉलम रखना निश्चित रूप से एक अच्छा विचार नहीं है, क्योंकि प्राथमिक कुंजी क्लस्टर हैं और guids यादृच्छिक हैं। इसका मतलब है कि जब भी आप एक नई पंक्ति डालते हैं तो आपकी तालिका अनिवार्य रूप से डिस्क पर पुनर्गठित की जा रही है। लोग आम तौर पर सलाह देते हैं कि प्राथमिक कुंजी अनुक्रमिक, हमेशा बढ़ते प्रकार होनी चाहिए ताकि प्रत्येक नई पंक्ति तालिका के अंत में आ जाए।
जोड़ा लेखक Matt Hamilton, स्रोत
एक प्राथमिक कुंजी डिफ़ॉल्ट रूप से क्लस्टर्ड इंडेक्स द्वारा समर्थित होती है लेकिन इसे हटाया जा सकता है (क्लस्टर इंडेक्स)।
जोड़ा लेखक Andrei Rînea, स्रोत

एक प्राथमिक कुंजी को एक ऑटोइनक्रिकमेंटिंग फील्ड नहीं होना चाहिए, कई मामलों में इसका मतलब यह है कि आप अपनी टेबल संरचना को जटिल बना रहे हैं।

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

तकनीकी शर्तों में, यह क्षेत्र होना चाहिए कि ट्यूपल में हर दूसरे क्षेत्र पूरी तरह से कार्यात्मक रूप से निर्भर है। (यदि ऐसा नहीं है तो आपको सामान्यीकृत करने की आवश्यकता हो सकती है)।

अभ्यास में, प्रदर्शन समस्याओं का अर्थ यह हो सकता है कि आप तालिकाओं को मर्ज करते हैं, और एक वृद्धिशील क्षेत्र का उपयोग करते हैं, लेकिन मुझे लगता है कि समयपूर्व अनुकूलन बुराई होने के बारे में कुछ याद है ...

0
जोड़ा

मैंने हमेशा यह भी सुना है कि ऑटो-इंक्रिमेंटिंग इंट प्रदर्शन के लिए अच्छा है, भले ही आप इसका उपयोग नहीं करते हैं।

0
जोड़ा

चूंकि आप प्रतिकृति कर रहे हैं, इसलिए आपकी सही पहचान कुछ स्पष्ट है। मैं आपकी GUID को प्राथमिक कुंजी बनाउंगा लेकिन नॉनक्स्टस्टर क्योंकि आप newsequentialid का उपयोग नहीं कर सकते हैं। यह मुझे आपके सबसे अच्छे पाठ्यक्रम के रूप में चिपकता है। यदि आप इसे पीके नहीं बनाते हैं, लेकिन उस पर एक अनूठी अनुक्रमणिका डालते हैं, जल्दी या बाद में जो लोग सिस्टम को बनाए रख सकते हैं ताकि एफके रिश्तों को सही ढंग से बग पेश नहीं किया जा सके।

0
जोड़ा

बस कूदते हुए, क्योंकि मैट ने मुझे थोड़ा सा बाइट किया।

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

एक सीईक्स के बिना एक टेबल सिर्फ एक हीप है। पीके के बिना एक टेबल को अक्सर "टेबल नहीं" माना जाता है। पीके और सीईक्स दोनों अवधारणाओं को अलग से समझना सबसे अच्छा है ताकि आप डेटाबेस डिज़ाइन में समझदार निर्णय ले सकें।

लूटना

0
जोड़ा

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

0
जोड़ा
असल में, यह गलत है - जैसा कि किम्बर्ली ट्रिप (इंडेक्सिंग की रानी) स्पष्ट रूप से दिखाता है: अच्छा क्लस्टरर्ड इंडेक्स बढ़ाना INSERT प्रदर्शन होगा! sqlskills.com/BLOGS/KIMBERLY/post/…
जोड़ा लेखक marc_s, स्रोत
मैं उस स्पष्ट रूप से को कॉल नहीं करूँगा :) वह सामान्य सिद्धांतों के बारे में बात करती है, उसके कथन का समर्थन नहीं करती है, ठीक है, कुछ भी, जबकि मैं अपने अभ्यास में एक बहुत ही विशिष्ट परिदृश्य के बारे में बात कर रहा हूं: संभावित रूप से सैकड़ों लाखों रिकॉर्ड्स की गैर-खाली तालिका में थोक-आवेषण, जिसे तब कभी याद नहीं किया जाता है और न ही यादृच्छिक-पढ़ने वाले मोड में पहुंचाया जाता है बल्कि इसकी पूरी तरह से स्कैन किया जाता है। मुझे लगता है कि इंडेक्स की तुलना में खेलने पर और अधिक कारक हो सकते हैं। हमेशा अपने अनुकूलन बच्चों का परीक्षण करें।
जोड़ा लेखक zvolkov, स्रोत

इंडेक्स से निपटने पर, आपको यह निर्धारित करना होगा कि आपकी तालिका का उपयोग किस प्रकार किया जा रहा है। यदि आप प्राथमिक रूप से 1000 पंक्तियों को एक दूसरे से सम्मिलित कर रहे हैं और कोई पूछताछ नहीं कर रहे हैं, तो क्लस्टर्ड इंडेक्स प्रदर्शन के लिए एक हिट है। यदि आप एक सेकंड में 1000 प्रश्न कर रहे हैं, तो इंडेक्स नहीं होने से बहुत खराब प्रदर्शन होगा। क्वेरी / इंडेक्स को ट्यून करने का प्रयास करते समय करने के लिए सबसे अच्छी बात SQL सर्वर में क्वेरी प्लान विश्लेषक और एसक्यूएल प्रोफाइलर का उपयोग करना है। यह आपको दिखाएगा कि आप महंगे टेबल स्कैन या अन्य प्रदर्शन अवरोधकों में कहां चल रहे हैं।

GUID बनाम आईडी तर्क के लिए, आप ऑनलाइन लोगों को ढूंढ सकते हैं जो दोनों की कसम खाता है। मुझे हमेशा GUID का उपयोग करने के लिए सिखाया जाता है जब तक कि मेरे पास वास्तव में कोई अच्छा कारण न हो। जेफ की एक अच्छी पोस्ट है जो GUID का उपयोग करने के कारणों के बारे में बात करती है: http: //www.codinghorror .com / ब्लॉग / अभिलेखागार / 000817.html

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

[संपादित करें] @ मैट, GUID / आईडी बहस पर कुछ और शोध करने के बाद मैं इस पोस्ट में आया था। जैसा कि मैंने पहले उल्लेख किया था, कोई सही सही या गलत जवाब नहीं है। यह आपकी विशिष्ट कार्यान्वयन आवश्यकताओं पर निर्भर करता है। लेकिन प्राथमिक कुंजी के रूप में GUID का उपयोग करने के लिए ये कुछ मान्य कारण हैं:

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

     

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

     

यदि आप सोचते हैं आपको तालिका में प्रश्न के लिए प्रतिकृति को सक्षम करने की आवश्यकता हो सकती है - तो आप पीके को एक अद्वितीय पहचानकर्ता बना सकते हैं और GUID फ़ील्ड को ROWGUIDCOL के रूप में चिह्नित कर सकते हैं। प्रतिकृति के लिए इस विशेषता के साथ एक विशिष्ट मूल्यवान guid फ़ील्ड की आवश्यकता होगी, और यदि कोई मौजूद नहीं है तो यह एक जोड़ देगा। यदि कोई उपयुक्त फ़ील्ड मौजूद है, तो यह केवल उस व्यक्ति का उपयोग करेगा।

     

पीके के लिए GUID का उपयोग करने के लिए अभी तक एक और बड़ा लाभ यह तथ्य है कि मूल्य वास्तव में अद्वितीय है - केवल यह सर्वर द्वारा उत्पन्न सभी मानों में से नहीं, लेकिन सभी कंप्यूटर - चाहे वह आपका डीबी सर्वर, वेब सर्वर, ऐप सर्वर, या क्लाइंट मशीन हो। बहुत सारी आधुनिक भाषा में अब एक वैध guid उत्पन्न करने की क्षमता है - .NET में आप System.Guid.NewGuid का उपयोग कर सकते हैं। विशेष रूप से कैश किए गए मास्टर-विवरण डेटासेट से निपटने पर यह बहुत आसान है। आपको प्रतिबद्ध होने से पहले अपने रिकॉर्ड को एक साथ जोड़ने के लिए आपको पागल अस्थायी कुंजीपटल योजनाओं को नियोजित नहीं करना पड़ेगा। जब आप रिकॉर्ड बनाए जाते हैं तो आप प्रत्येक नए रिकॉर्ड के स्थायी कुंजी मान के लिए ऑपरेटिंग सिस्टम से बिल्कुल एक बिल्कुल मान्य नया ग्रिड प्राप्त करते हैं।

     

http://forums.asp.net/t/264350.aspx

0
जोड़ा
चित्त आकर्षण करनेवाला। यदि प्रदर्शन एक मुद्दा बन जाता है तो मैं "पृष्ठ विभाजन और अनुक्रमणिका पुनर्निर्माण" विकल्प को देखूंगा। उसके लिए धन्यवाद।
जोड़ा लेखक Matt Hamilton, स्रोत
Kimberly Tripp के प्राथमिक के रूप में GUID पढ़ें और / या क्लस्टरिंग कुंजी और डिस्क स्थान सस्ता है - यह नहीं बिंदु है! और उसके उत्कृष्ट ब्लॉग पोस्टों में से कई और - वह स्पष्ट रूप से दिखाती है कि GUID पर क्लस्टरिंग कुंजी कितनी खराब है कॉलम है इसके अलावा - हॉटस्पॉट्स एक मिथक है जो लंबे समय से डिबंक की जाती है - अब SQL सर्वर 6.5 के बाद क
जोड़ा लेखक marc_s, स्रोत