प्राथमिक कुंजी तार्किक अर्थ (विशिष्ट रूप से आपकी पंक्तियों की पहचान) में - हाँ, बिल्कुल, पूरी समझ में आता है।
लेकिन: एसक्यूएल सर्वर में, प्राथमिक कुंजी अपनी मेज पर डिफ़ॉल्ट भी क्लस्टरिंग कुंजी से है, और एक क्लस्टरिंग कुंजी ROWGUID के रूप में उपयोग करते हुए एक वास्तव में बहुत बुरा विचार है। क्लस्टरिंग के लिए GUID का उपयोग न करने के कारण गहन कारणों से Kimberly Tripp के उत्कृष्ट GUIDs as a PRIMARY and/or the clustering key आलेख देखें।
चूंकि GUID परिभाषा यादृच्छिक रूप से है, तो आपके पास एक भयानक अनुक्रमणिका विखंडन होगा और इस प्रकार सम्मिलित करने, अपडेट करने, हटाने और बयानों का चयन करने के लिए वास्तव में वास्तव में खराब प्रदर्शन होगा।
इसके अलावा, चूंकि क्लस्टरिंग कुंजी को आपकी तालिका में प्रत्येक और गैर-क्लस्टर इंडेक्स के प्रत्येक फ़ील्ड में जोड़ा जा रहा है, इसलिए आप डिस्क पर और साथ ही सर्वर रैम पर बहुत सारी जगह बर्बाद कर रहे हैं - जब 16-बाइट GUID बनाम 4-बाइट INT का उपयोग कर।
तो: हाँ, प्राथमिक कुंजी के रूप में, एक ROWGUID की योग्यता होती है - लेकिन यदि आप इसका उपयोग करते हैं, तो निश्चित रूप से उस कॉलम को तालिका में अपनी क्लस्टरिंग कुंजी के रूप में उपयोग करने से बचें! इसके लिए एक आईएनटी पहचान() या कुछ इसी तरह का उपयोग करें।
एक क्लस्टरिंग कुंजी के लिए, आदर्श आप चार सुविधाओं के लिए दिखना चाहिए:
- स्थिर (कभी नहीं बदल रहा है)
- अद्वितीय
- संभव के रूप में छोटे
- बढ़ती
आईएनटी पहचान() आदर्श रूप से जरूरत है कि उपयुक्त है। और हाँ - क्लस्टरिंग कुंजी अद्वितीय होनी चाहिए क्योंकि इसका उपयोग तालिका में एक पंक्ति को शारीरिक रूप से ढूंढने के लिए किया जाता है - यदि आप एक स्तंभ चुनते हैं जिसे अद्वितीय होने की गारंटी नहीं दी जा सकती है, तो SQL सर्वर वास्तव में आपके क्लस्टरिंग कुंजी पर चार-बाइट अनन्यफायर जोड़ देगा - फिर, ऐसा कुछ नहीं जो आप चाहते हैं ....
The Clustered Index Debate Continues देखें - किम ट्रिप ("एसक्यूएल सर्वर इंडेक्सिंग की रानी") द्वारा एक और अद्भुत और अंतर्दृष्टिपूर्ण लेख जिसमें वह इन सभी आवश्यकताओं को बहुत अच्छी तरह से और अच्छी तरह से बताती है ।
मार्क
स्रोत
2009-10-30 19:35:34
GUID का आकार यहां कोई मुद्दा नहीं होना चाहिए। इस सवाल के सीधा जवाब में "एक और क्लस्टर्ड इंडेक्स चुनना न भूलें" चेतावनी को छोड़कर यहां कुछ भी अतिरिक्त पेशकश नहीं की गई है। चूंकि ROWGUID आंतरिक रूप से पंक्ति आईडी भी है, इसलिए कोई बर्बाद जगह नहीं होनी चाहिए क्योंकि सूचकांक (पंक्ति की आईडी) का लक्ष्य वैसे भी लिखा जाएगा। या क्या ऑप्टिमाइज़ेशन की एक सीमा/कमी है जिसका अर्थ है कि एमएस को सूचकांक में दो बार GUID लिखना चाहिए, भले ही यह ROWGUID है? मुझे शक होगा, लेकिन अगर आप अन्यथा जानते हैं तो कृपया स्पष्टीकरण दें। –
@CodeChief: * क्लस्टरिंग कुंजी * का आकार ** बहुत अधिक ** SQL सर्वर में एक समस्या है! यह वास्तव में जितना संभव हो उतना छोटा होना चाहिए, क्योंकि यह उसी तालिका में ** सभी ** गैर-क्लस्टर इंडेक्स में भी शामिल है। 4 बाइट बनाम 16 बाइट एक ** विशाल ** अंतर बनाता है यदि आपके पास 100 मिलियन पंक्तियां और 15 नॉनक्लस्टर्ड इंडेक्स हैं! –
यदि यह स्पष्ट नहीं था तो मैं वास्तव में सुझाव दे रहा हूं कि क्लस्टर्ड इंडेक्स के साथ इसका कोई लेना-देना नहीं है! यदि आपको एमएसडीएन में दस्तावेज के रूप में अस्वीकृत न्यूज़क्वेंटिड() को अवश्य करना चाहिए और पहले ही यहां दूसरों द्वारा उत्तर दिया गया है। वैसे भी बड़े डेटाबेस के बारे में बात करते हैं, अगर वे बड़े ग्राहकों के लिए हैं और महत्वपूर्ण हैं तो आपको स्केलेबिलिटी की योजना बनाना चाहिए या आवश्यकता के रूप में बेहद फायदेमंद होना चाहिए, जो किसी भी तरह से रॉविल की ओर जाता है। –