क्या पहचानकर्ता कॉलम के लिए एक अद्वितीय पहचानकर्ता (GUID) या एक बड़ा उपयोग करना बेहतर है?

Question

SQL सर्वर के लिए एक पहचान कॉलम के लिए एक अद्वितीय पहचानकर्ता (GUID) या एक बड़ा उपयोग करना बेहतर है?

Answer 1

है कि आप क्या कर रहे हैं पर निर्भर करता है:

• गति प्राथमिक चिंता का विषय है, तो एक सादे पुराने int पर्याप्त शायद बड़ा है।
• यदि आपके पास वास्तव में 2 अरब से अधिक (बी के साथ)) रिकॉर्ड होंगे, तो bigint या अनुक्रमिक मार्गदर्शिका का उपयोग करें।
• यदि आपको दूरस्थ रूप से बनाए गए रिकॉर्ड्स के साथ आसानी से सिंक्रनाइज़ करने में सक्षम होना चाहिए, तो Guid वास्तव में बहुत अच्छा है।

अद्यतन
कुछ अतिरिक्त (कम स्पष्ट) पर GUIDs नोट:

• वे अनुक्रमित पर कठिन हो सकता है, और है कि डेटाबेस प्रदर्शन के मुख्य
• आप उपयोग कर सकते हैं करने के लिए कटौती इंडेक्सिंग प्रदर्शन में से कुछ को वापस पाने के लिए अनुक्रमिक मार्गदर्शिकाएं, लेकिन बिंदु दो में उपयोग की गई कुछ यादृच्छिकता को छोड़ दें।
• हाथों से हाथों को डीबग करना मुश्किल हो सकता है (where id='xxx-xxx-xxxxx'), लेकिन आप उसमें से कुछ अनुक्रमिक guids के साथ-साथ (where id='xxx-xxx' + '123') प्राप्त कर सकते हैं।
• इसी कारण से, Guids आईडी-आधारित सुरक्षा हमलों को और अधिक कठिन बना सकता है- लेकिन असंभव नहीं है। (आप केवल 'http://example.com?userid=xxxx' टाइप नहीं कर सकते हैं और किसी और के खाते के परिणाम प्राप्त करने की उम्मीद कर सकते हैं)।

Answer 2

सामान्य रूप से मैं BIGINTGUID (जैसे कि guids बड़े और धीमे होते हैं) पर सलाह देते हैं, लेकिन सवाल यह है कि, क्या आपको इसकी आवश्यकता भी है? (यानी आप प्रतिकृति कर रहे हैं?) यदि आप 2 अरब से कम पंक्तियों की अपेक्षा कर रहे हैं, पारंपरिक INT ठीक रहेगा।

Answer 3

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

Answer 4

आपको जो चाहिए वह निर्भर करता है। डीबी प्रदर्शन पूर्णांक से प्राप्त होगा जबकि GUID प्रतिकृति के लिए उपयोगी हैं और डीबी से वापस सुनने की आवश्यकता नहीं है, पहचान किस प्रकार बनाई गई है, यानी कोड पंक्ति में डालने से पहले GUID पहचान बना सकता है।

Answer 5

यह वास्तव में निर्भर करता है कि आप तस्वीर में प्रतिकृति की उम्मीद कर रहे हैं या नहीं। प्रतिकृति के लिए एक पंक्ति UUID की आवश्यकता होती है, इसलिए यदि आप ऐसा करने की योजना बना रहे हैं तो आप इसे आगे भी कर सकते हैं।

Answer 6

यदि आप विलय प्रतिकृति का उपयोग करने की योजना बना रहे हैं तो ROWGUIDCOL प्रदर्शन (see here for info) के लिए फायदेमंद है। अन्यथा हमें 'बेहतर' की परिभाषा के बारे में अधिक जानकारी चाहिए; क्या के लिए बेहतर है?

Answer 7

क्या आप प्रतिकृति कर रहे हैं या क्या आपके पास ऐसे लोग हैं जो डिस्कनेक्ट किए गए डेटाबेस चलाते हैं जिन्हें एक GUID का उपयोग करने की आवश्यकता होती है। अन्यथा मैं एक int या bigint के लिए जाना होगा। लंबे समय तक निपटने के लिए वे बहुत आसान हैं।

Answer 8

जेफ एटवुड ने पहले ही in this comprehensive post का उत्तर दिया है।

Answer 9

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

Answer 10

मैं एंड्रयू रोलिंग के साथ हूं।

अब आप अंतरिक्ष दक्षता पर बहस कर सकते हैं। एक int क्या है, 8 बाइट अधिकतम? एक गाइड बहुत अधिक समय जा रहा है।

लेकिन मेरे पास वरीयता के लिए दो मुख्य कारण हैं: पठनीयता और पहुंच का समय। GUID की तुलना में मेरे लिए संख्याएं आसान हैं (क्योंकि मैं हमेशा अगली/पिछली रिकॉर्ड आसानी से पा सकता हूं)।

एक्सेस समय के लिए, ध्यान दें कि कुछ डीबी को GUID के साथ बड़ी समस्याएं शुरू हो सकती हैं। मुझे पता है कि यह MySQL (MySQL InnoDB Primary Key Choice: GUID/UUID vs Integer Insert Performance) के साथ मामला है। यह SQL सर्वर के साथ कोई समस्या नहीं हो सकती है, लेकिन यह देखने के लिए कुछ है।

मैं आईएनटी या बिगिनट के साथ छड़ी कहूंगा। एकमात्र बार मुझे लगता है कि आप चाहते हैं कि GUID तब होगा जब आप उन्हें बाहर निकालने जा रहे हैं और नहीं चाहते हैं कि लोग सुरक्षा कारणों से अन्य रिकॉर्ड की आईडी अनुमान लगा सकें।

Answer 11

GUID का उपयोग करने के लिए कुछ और पहलू या आवश्यकताएं हो सकती हैं।

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