एक 128-बिट GUID (uniqueidentifier ) कुंजी निश्चित रूप से 32-बिट int . से 4x बड़ी है चाबी। हालांकि, कुछ प्रमुख लाभ हैं:
- सामग्री मर्ज करते समय कोई "पहचान सम्मिलित" समस्या नहीं
- यदि आप NEWSEQUENTIALID() के बजाय COMB मान का उपयोग करते हैं, तो आपको एक "मुफ़्त" INSERT टाइमस्टैम्प मिलता है। आप
SELECT. भी कर सकते हैं यदि आप कुछ फैंसीCAST(). के साथ चाहते हैं तो दिनांक/समय सीमा के आधार पर प्राथमिक कुंजी से कॉल. - वे विश्व स्तर पर अद्वितीय हैं, जो समय-समय पर बहुत उपयोगी साबित होते हैं।
- चूंकि उच्च-जल चिह्नों को ट्रैक करने की कोई आवश्यकता नहीं है, इसलिए आपकी BL परत SQL सर्वर के बजाय मान निर्दिष्ट कर सकती है, इस प्रकार
SELECT scope_identity()के चरण को समाप्त कर सकती है। डालने के बाद प्राथमिक कुंजी प्राप्त करने के लिए। - यदि यह दूर से भी संभव है कि आपके पास 2 बिलियन से अधिक रिकॉर्ड हो सकते हैं, तो आपको
bigintका उपयोग करना होगा (64 बिट्स) के बजायint. एक बार जब आप ऐसा कर लेते हैं, तोuniqueidentifierbigint. से केवल दोगुना बड़ा है । - GUIDs का उपयोग करने से URL आदि में कुंजियों को प्रकट करना सुरक्षित हो जाता है, बिना "अनुमान-द-आईडी" हमलों के लिए खुद को उजागर किए बिना।
- डिस्क से SQL सर्वर पृष्ठों को कैसे लोड करता है और कैसे प्रोसेसर अब ज्यादातर 64-बिट हैं, इसके बीच, सिर्फ इसलिए कि एक संख्या 32 के बजाय 128 बिट्स है, इसका मतलब यह नहीं है कि तुलना करने में 4x अधिक समय लगता है। पिछले परीक्षण में मैंने देखा कि GUID लगभग उतने ही तेज़ हैं।
- इंडेक्स का आकार कितने पर निर्भर करता है कॉलम शामिल हैं। हालांकि GUID स्वयं बड़े हैं, अतिरिक्त 8 या 12 बाइट्स अनुक्रमणिका के अन्य स्तंभों की तुलना में महत्वहीन हो सकते हैं।
अंत में, पूर्णांकों का उपयोग करके कुछ छोटे प्रदर्शन लाभ को निचोड़ना GUID के लाभों को खोने के लायक नहीं हो सकता है। अनुभवजन्य रूप से इसका परीक्षण करें और स्वयं निर्णय लें।
व्यक्तिगत रूप से, मैं अभी भी स्थिति के आधार पर दोनों का उपयोग करता हूं, लेकिन मेरे मामले में निर्णायक कारक वास्तव में कभी भी प्रदर्शन के लिए नीचे नहीं आया है।
