विशिष्ट पहचानकर्ता बनाम पहचान बनाम सामग्री कोड -- जो प्राथमिक कुंजी के लिए सबसे अच्छा विकल्प है?

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

आपको वास्तव में दो मुद्दों को अलग रखना होगा:

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

डिफ़ॉल्ट रूप से, SQL सर्वर तालिका पर प्राथमिक कुंजी का उपयोग क्लस्टरिंग कुंजी के रूप में भी किया जाता है - लेकिन ऐसा होने की आवश्यकता नहीं है! पिछली GUID-आधारित प्राथमिक/क्लस्टर कुंजी को दो अलग-अलग कुंजियों में विभाजित करते समय मैंने व्यक्तिगत रूप से बड़े पैमाने पर प्रदर्शन लाभ देखा है - GUID पर प्राथमिक (तार्किक) कुंजी , और एक अलग INT IDENTITY(1,1) . पर क्लस्टरिंग (ऑर्डरिंग) कुंजी कॉलम।

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

हाँ, मुझे पता है - वहाँ newsequentialid() है SQL सर्वर 2005 और बाद के संस्करणों में - लेकिन यह भी सही मायने में और पूरी तरह से अनुक्रमिक नहीं है और इस प्रकार GUID जैसी ही समस्याओं से ग्रस्त है - बस थोड़ा कम प्रमुखता से।

फिर विचार करने के लिए एक और मुद्दा है:एक टेबल पर क्लस्टरिंग कुंजी आपकी टेबल पर प्रत्येक गैर-क्लस्टर इंडेक्स पर प्रत्येक प्रविष्टि में भी जोड़ दी जाएगी - इस प्रकार आप वास्तव में यह सुनिश्चित करना चाहते हैं कि यह जितना संभव हो उतना छोटा हो। आमतौर पर, एक INT 2+ अरब पंक्तियों के साथ अधिकांश तालिकाओं के लिए पर्याप्त होना चाहिए - और GUID . की तुलना में क्लस्टरिंग कुंजी के रूप में, आप स्वयं को डिस्क और सर्वर मेमोरी में सैकड़ों मेगाबाइट संग्रहण सहेज सकते हैं।

त्वरित गणना - INT . का उपयोग करके बनाम GUID प्राथमिक और क्लस्टरिंग कुंजी के रूप में:

1'000'000 पंक्तियों वाली आधार तालिका (3.8 एमबी बनाम 15.26 एमबी)
6 गैर-संकुल अनुक्रमणिका (22.89 एमबी बनाम 91.55 एमबी)

कुल:25 एमबी बनाम 106 एमबी - और वह सिर्फ एक टेबल पर है!

विचार के लिए कुछ और भोजन - किम्बर्ली ट्रिप द्वारा उत्कृष्ट सामग्री - इसे पढ़ें, इसे फिर से पढ़ें, इसे पचाएं! यह वास्तव में SQL सर्वर अनुक्रमण सुसमाचार है।

जब तक आपके पास बहुत अच्छा कारण . न हो , मैं INT IDENTITY . का उपयोग करने का तर्क दूंगा लगभग हर "वास्तविक" डेटा तालिका के लिए उनकी प्राथमिक कुंजी के लिए डिफ़ॉल्ट के रूप में - यह अद्वितीय है, यह स्थिर है (कभी नहीं बदलता है), यह संकीर्ण है, यह लगातार बढ़ रहा है - सभी अच्छे गुण जिसे आप अपने SQL सर्वर तालिकाओं के तेज़ और विश्वसनीय प्रदर्शन के लिए क्लस्टरिंग कुंजी में रखना चाहते हैं!

यदि आपके पास कुछ "प्राकृतिक" कुंजी मान है जिसमें वे सभी गुण भी हैं, तो आप सरोगेट कुंजी के बजाय इसका उपयोग भी कर सकते हैं। लेकिन दो अधिकतम की चर-लंबाई के तार। मेरी राय में प्रत्येक 20 वर्ण उन आवश्यकताओं को पूरा नहीं करते हैं।