2009-12-22 18 views
6

क्या आपके प्राथमिक/सरोगेट कुंजी कॉलम, या एक धारावाहिक "पहचान" पूर्णांक कॉलम के रूप में एक GUID (UniqueIdentifier) ​​का उपयोग करना बेहतर है; और क्यों क्या यह बेहतर है? आप किस परिस्थिति में एक दूसरे के ऊपर चयन करेंगे?SQL सर्वर डेटाबेस में सबसे आम आईडी प्रकार कौन सा है, और कौन सा बेहतर है?

+0

इस विषय पर कई मौजूदा चर्चाएं हैं, जो चीजों को अच्छी तरह से कवर करती हैं। –

+0

हां, एसओ पर पहले से ही कई प्रश्न हैं जो इस सटीक प्रश्न से निपटते हैं। – BBlake

+1

बस एक तरफ: संभवतः हमें एसओ ज्ञान आधार खोजने के बेहतर तरीकों के बारे में सोचना होगा। मैं बस इसके साथ खोज कर रहा हूं लेकिन बहुत सफलता प्राप्त कर रहा हूं। ऐसा लगता है कि आप अलग-अलग तरीकों से नीचे आ सकते हैं। – Lisa

उत्तर

9

मैं व्यक्तिगत रूप से अपनी प्राथमिक और क्लस्टरिंग कुंजी के लिए व्यक्तिगत पहचान का उपयोग करता हूं।

आपको प्राथमिक कुंजी को अलग रखना होगा जो एक तार्किक निर्माण है - यह विशिष्ट रूप से आपकी पंक्तियों की पहचान करता है, यह अद्वितीय और स्थिर होना चाहिए और न्यूल नहीं होना चाहिए। एक GUID एक प्राथमिक कुंजी के लिए भी अच्छी तरह से काम करता है - क्योंकि यह अद्वितीय होने की गारंटी है। यदि आप SQL सर्वर प्रतिकृति का उपयोग करते हैं, तो आपकी प्राथमिक कुंजी के रूप में एक GUID एक अच्छा विकल्प है, क्योंकि उस स्थिति में, आपको किसी विशिष्ट रूप से पहचानने वाले GUID कॉलम की आवश्यकता है।

SQL सर्वर में क्लस्टरिंग कुंजी एक भौतिक निर्माण डेटा के भौतिक क्रम के लिए उपयोग किया जाता है, और सही होने के लिए बहुत मुश्किल है। आम तौर पर, एसक्यूएल सर्वर, किम्बर्ली ट्रिप पर इंडेक्सिंग की रानी को भी एक अच्छी क्लस्टरिंग कुंजी की आवश्यकता होती है, जो संभवतः संकीर्ण, स्थिर, यथासंभव संकीर्ण, और आदर्श रूप से बढ़ती जा रही है (जो एक पहचान पहचान है)।,

एक GUID एक क्लस्टरिंग कुंजी के लिए एक बहुत बुरी विकल्प है क्योंकि यह व्यापक, पूरी तरह से यादृच्छिक है:

यहाँ अनुक्रमण पर उसके लेख देखें , और इस प्रकार खराब सूचकांक विखंडन और खराब प्रदर्शन की ओर जाता है। साथ ही, क्लस्टरिंग कुंजी पंक्ति प्रत्येक गैर-क्लस्टर (अतिरिक्त) इंडेक्स की प्रत्येक प्रविष्टि में भी संग्रहीत होती है, इसलिए आप वास्तव में इसे छोटा रखना चाहते हैं - GUID 16 बाइट बनाम INT 4 बाइट है, और कई गैर-क्लस्टर सूचकांक और कई मिलियन पंक्तियों के साथ, यह एक बड़ा अंतर बनाता है।

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

+2

को किम ट्रिप से प्यार होना चाहिए। –

+0

तो क्या तालिका में दो "आईडी" कॉलम होंगे? एक गाइड और एक पहचान पहचान? – Nate

+0

@Nate: आप - GUID टाइप करने के "ऑब्जेक्टिड" और टाइप INT पहचान की "एंट्रीआईडी" कर सकते हैं - जो काम करेगा, हां। –

5

बहुत ही कम से कम GUID का उपयोग करें।

स्टोरेज उद्देश्यों के लिए प्राथमिक कुंजी/सरोगेट कुंजी का उपयोग करें।

इसके अलावा यह डेटा के साथ मानव संपर्क के लिए आसान बना देगा।

इंडेक्स बनाना भी बहुत अधिक कुशल होगा।

एक दोहराया प्रणाली है जहाँ आप विशिष्टता की गारंटी करने की जरूरत है

7

उपयोग एक GUID देखें।

इनट्स का उपयोग करें जहां आपके पास एक गैर-प्रतिकृति डेटाबेस है और आप प्रदर्शन को अधिकतम करना चाहते हैं।

1

यदि आपको लगता है कि आपको डेटाबेस के बाहर डेटा का उपयोग करने की आवश्यकता होगी, यानी अन्य डेटाबेस)। कुछ तर्क देंगे, यह हमेशा मामला है, लेकिन यह एक निर्णय कॉल है।

2

यह एक बहस विषय है, लेकिन मैं कुछ कारणों से पहचान की ओर झुकता हूं। सबसे पहले, एक पूर्णांक केवल 16 बाइट GUID बनाम 4 बाइट्स है। इसका मतलब संकुचित सूचकांक और अधिक कुशल प्रश्न हैं। दूसरा, हम @@IDENTITY और SCOPE_IDENTITY का उपयोग संग्रहीत प्रोसेस आदि में बहुत अधिक करते हैं, जो कि GUID के साथ विंडो से बाहर निकलता है।

यहां एक अच्छा छोटा article by Jeff Atwood है।

+0

+++++++ 1 इच्छा मैं आपको एक से अधिक बार ऊपर उठा सकता हूं :-) –

+0

मैं इसकी सराहना करता हूं मार्क! –

2

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

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

यह सब कुछ है जो आप संग्रहित कर रहे हैं और कैसे। वे लोग जो कहते हैं "कभी भी ग्रिड का उपयोग न करें!" सिर्फ एफयूडी फैल रहे हैं, लेकिन वे हर समस्या का जवाब भी नहीं हैं।

4

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

उदाहरण के लिए, यदि आप सुनिश्चित नहीं हैं कि 32-बिट पूर्णांक करेगा, तो 64-बिट पूर्णांक का उपयोग करें।

आप इन अन्य अतः विचार विमर्श उपयोगी लग सकते:

How do you like your primary keys?

What’s the best practice for Primary Keys in tables?

Picking the best primary key + numbering system.

और अगर आप "प्राथमिक कुंजी के लिए" अतः यहाँ खोज, आप मिल जाएगा उन और बहुत अधिक उपयोगी चर्चाएं।

+0

आईएनटी आपको 2 बिलियन पंक्तियां देता है - यह आमतौर पर पर्याप्त है :-) –

2

मेरा मानना ​​है कि यह लगभग हमेशा एक क्रमबद्ध पहचान पूर्णांक है, लेकिन कुछ असहमत होंगे। यह स्थिति पर निर्भर करता है।

पहचान के कारण दक्षता और सादगी है। यह छोटा है। अधिक आसानी से अनुक्रमित।यह महान क्लस्टर सूचकांक बनाता है। नए रिकॉर्ड के रूप में कम विखंडन क्रम में रखा जाता है। जुड़ने पर इंडेक्स के लिए बढ़िया। एक डीबी में रिकॉर्ड नजरअंदाज जब आसान है।

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

संबंधित मुद्दे