मैं आपके साथ 100% सहमत हूँ - INT IDENTITY . का उपयोग करके बहुत बेहतर है!
GUID आपकी प्राथमिक कुंजी के लिए एक स्वाभाविक विकल्प प्रतीत हो सकते हैं - और यदि आपको वास्तव में चाहिए, तो आप संभवतः तालिका की प्राथमिक कुंजी के लिए इसका उपयोग करने के लिए तर्क दे सकते हैं। मैं पुरज़ोर अनुशंसा करता हूँ नहीं करने के लिए GUID कॉलम का उपयोग क्लस्टरिंग कुंजी . के रूप में करता है , जो SQL सर्वर डिफ़ॉल्ट रूप से करता है, जब तक कि आप इसे विशेष रूप से नहीं बताते।
आपको वास्तव में दो मुद्दों को अलग रखना होगा:
1) प्राथमिक कुंजी एक तार्किक निर्माण है - उम्मीदवार कुंजी में से एक जो आपकी तालिका में प्रत्येक पंक्ति को विशिष्ट और विश्वसनीय रूप से पहचानती है। यह कुछ भी हो सकता है, वास्तव में - एक आईएनटी, एक GUID, एक स्ट्रिंग - वह चुनें जो आपके परिदृश्य के लिए सबसे अधिक समझ में आता है।
2) क्लस्टरिंग कुंजी (स्तंभ या कॉलम जो टेबल पर "क्लस्टर इंडेक्स" को परिभाषित करते हैं) - यह एक भौतिक है भंडारण से संबंधित चीज, और यहां, एक छोटा, स्थिर, लगातार बढ़ता हुआ डेटा प्रकार आपका सबसे अच्छा विकल्प है - INT या BIGINT आपके डिफ़ॉल्ट विकल्प के रूप में।
डिफ़ॉल्ट रूप से, SQL सर्वर तालिका पर प्राथमिक कुंजी का उपयोग क्लस्टरिंग कुंजी के रूप में भी किया जाता है - लेकिन ऐसा होने की आवश्यकता नहीं है! मैंने व्यक्तिगत रूप से पिछले GUID-आधारित प्राथमिक/क्लस्टर कुंजी को दो अलग-अलग कुंजी - GUID पर प्राथमिक (तार्किक) कुंजी, और क्लस्टरिंग (ऑर्डरिंग) कुंजी को एक अलग INT पहचान (1,) में तोड़ते समय बड़े पैमाने पर प्रदर्शन लाभ देखा है। 1) कॉलम।
किम्बर्ली ट्रिप - अनुक्रमण की रानी - और अन्य ने कई बार कहा है - क्लस्टरिंग कुंजी के रूप में एक GUID इष्टतम नहीं है, क्योंकि इसकी यादृच्छिकता के कारण, यह बड़े पैमाने पर पृष्ठ और अनुक्रमणिका विखंडन और आम तौर पर खराब प्रदर्शन की ओर ले जाएगा।
हाँ, मुझे पता है - वहाँ newsequentialid() है SQL सर्वर 2005 और बाद के संस्करणों में - लेकिन वह भी सही मायने में और पूरी तरह से अनुक्रमिक नहीं है और इस प्रकार GUID जैसी ही समस्याओं से ग्रस्त है - बस थोड़ा कम प्रमुखता से।
फिर विचार करने के लिए एक और मुद्दा है:एक टेबल पर क्लस्टरिंग कुंजी आपकी टेबल पर प्रत्येक गैर-क्लस्टर इंडेक्स पर प्रत्येक प्रविष्टि में भी जोड़ दी जाएगी - इस प्रकार आप वास्तव में यह सुनिश्चित करना चाहते हैं कि यह जितना संभव हो उतना छोटा हो। आमतौर पर, 2+ बिलियन पंक्तियों वाला एक INT अधिकांश तालिकाओं के लिए पर्याप्त होना चाहिए - और क्लस्टरिंग कुंजी के रूप में GUID की तुलना में, आप डिस्क और सर्वर मेमोरी में अपने आप को सैकड़ों मेगाबाइट स्टोरेज बचा सकते हैं।
त्वरित गणना - प्राथमिक और क्लस्टरिंग कुंजी के रूप में INT बनाम GUID का उपयोग करना:
- 1'000'000 पंक्तियों वाली आधार तालिका (3.8 एमबी बनाम 15.26 एमबी)
- 6 गैर-संकुल अनुक्रमणिका (22.89 एमबी बनाम 91.55 एमबी)
कुल:25 एमबी बनाम 106 एमबी - और वह सिर्फ एक टेबल पर है!
विचार के लिए कुछ और भोजन - किम्बर्ली ट्रिप द्वारा उत्कृष्ट सामग्री - इसे पढ़ें, इसे फिर से पढ़ें, इसे पचाएं! यह वास्तव में SQL सर्वर अनुक्रमण सुसमाचार है।
- प्राथमिक कुंजी और/या संकुल कुंजी के रूप में GUIDs
- संकुल अनुक्रमणिका बहस जारी है
- निरंतर बढ़ती हुई क्लस्टरिंग कुंजी - क्लस्टर्ड इंडेक्स डिबेट ..... फिर से!
- डिस्क स्पेस सस्ता है - यानी नहीं बात!
