GUID INT पहचान बनाम

Question

संभव डुप्लिकेट:
How do you like your primary keys?

मैं एक GUID उपयोग कर के लाभ, साथ ही उपयोग करते हुए और INT में एक पी के रूप में के लाभों के बारे में पता कर रहा हूँ एक डेटाबेस यह मानते हुए कि एक GUID एक 128 बिट आईएनटी है और सामान्य आईएनटी 32 बिट है, आईएनटी एक स्पेस सेवर है (हालांकि यह बिंदु आम तौर पर अधिकांश आधुनिक प्रणालियों में म्यूट होता है)।

अंत में, आप एक परिस्थिति में एक पीआईसी के रूप में एक आईएनटी का उपयोग करके खुद को किस परिस्थिति में देखेंगे?

Answer 1

किम्बर्ले ट्रिप (SQLSkills.com) में GUID के प्राथमिक कुंजी के रूप में उपयोग करने पर an article है। अनावश्यक ओवरहेड की वजह से वह इसके खिलाफ सलाह देती है।

Answer 2

डीबगिंग के दौरान एक आईएनटी निश्चित रूप से पढ़ने के लिए बहुत आसान है, और बहुत छोटा है।

हालांकि, मैं एक GUID का उपयोग करता हूं या किसी उत्पाद के लिए लाइसेंस कुंजी के समान होता हूं। आप जानते हैं कि यह अद्वितीय होगा, और आप जानते हैं कि यह अनुक्रमिक नहीं होगा।

Answer 3

प्राथमिक से विदेशी कुंजी संबंधों जैसे मूल्यों की तुलना करते समय, आईएनटी तेजी से होगा। यदि टेबल ठीक से अनुक्रमित होते हैं और तालिकाएं छोटी होती हैं, तो हो सकता है कि आप धीमे से अधिक न देख सकें, लेकिन आपको यह सुनिश्चित करने के लिए प्रयास करना होगा। आईएनटी पढ़ने के लिए भी आसान है, और अन्य लोगों के साथ संवाद। यह कहना बहुत आसान है, "क्या आप रिकॉर्ड 1234 देख सकते हैं?" इसके बजाय "क्या आप 031E9502-E283-4F87-9049-CE0E5C76B658 रिकॉर्ड देख सकते हैं?"

Answer 4

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

यदि आप अपने डेटाबेस के कुछ ऑटो-आईडी फ़ंक्शन का उपयोग करते हैं, तो डेटाबेस सिद्धांत में पूरी तरह से सुनिश्चित कर सकता है कि कोई डुप्लिकेशन नहीं है।

Answer 5

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

Answer 6

मुझे लगता है कि डेटाबेस भी महत्वपूर्ण है। एक MySQL परिप्रेक्ष्य से - आम तौर पर, डाटाटाइप जितना तेज़ प्रदर्शन उतना ही छोटा होता है। मैं केवल यदि इस कुंजी सीमा समान मूल्य के लिए पी के रूप में GUID का प्रयोग करेंगे http://kccoder.com/mysql/uuid-vs-int-insert-performance/

Answer 7

-

यह बहुत बनाम GUID पूर्णांक के लिए सच धारण करने के लिए लगता है। उदाहरण के लिए, उपयोगकर्ता आईडी (WinNT में उपयोगकर्ता GUIDs के साथ वर्णन करते हैं), या उपयोगकर्ता समूह आईडी। एक और उदाहरण। यदि आप दस्तावेजों के प्रबंधन के लिए वितरित प्रणाली विकसित करते हैं और दुनिया भर के विभिन्न स्थानों पर सिस्टम के विभिन्न हिस्सों में कुछ दस्तावेज बना सकते हैं। ऐसे मामले में मैं GUID का उपयोग करूंगा, क्योंकि यह गारंटी देता है कि वितरित सिस्टम के विभिन्न हिस्सों में बनाए गए 2 दस्तावेज़ों में एक ही आईडी नहीं होगी।

Answer 8

अपने प्रश्न का उत्तर देने के लिए: अंत में, आप एक परिस्थिति में एक पीआईसी के रूप में एक आईएनटी का उपयोग करके खुद को किस स्थिति में देखेंगे?

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

Answer 9

यदि डेटा एक डेटाबेस में रहता है (जैसा कि हम सामान्य रूप से लिखने वाले अनुप्रयोगों के लिए अधिकतर डेटा करते हैं), तो मैं IDENTITY का उपयोग करता हूं। यह आसान है, इस तरह इस्तेमाल करने का इरादा है, क्लस्टर्ड इंडेक्स को खंडित नहीं करता है और पर्याप्त से अधिक है। आप 2 बिलियन रिकॉर्ड्स पर कमरे से बाहर चले जाएंगे (यदि आप नकारात्मक मूल्यों का उपयोग करते हैं तो ~ 4 बिलियन), लेकिन यदि आप एक टेबल में कई रिकॉर्ड रखते हैं, तो आपके पास टोस्ट होगा, और फिर आपके पास डेटा वेयरहाउसिंग समस्या होगी।

यदि डेटा एकाधिक, स्वतंत्र डेटाबेस या तृतीय पक्ष सेवा के साथ इंटरफेस में रहता है, तो मैं GUID का उपयोग करूंगा जो पहले से ही जेनरेट की गई थी। एक अच्छा उदाहरण डेटाबेस में UserProfiles तालिका होगी जो उपयोगकर्ताओं को सक्रिय निर्देशिका में उपयोगकर्ताओं को उनके objectGUID के माध्यम से एप्लिकेशन में उनके उपयोगकर्ता प्रोफाइल के लिए मानचित्रित करता है जो उन्हें निर्दिष्ट सक्रिय निर्देशिका है।

Answer 10

INT एक अंतरिक्ष सेवर (हालांकि यह बिंदु आम तौर पर सबसे आधुनिक प्रणालियों में विवादास्पद है)।

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

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

Answer 11

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

Answer 12

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

बेशक, मैन्युअल प्रश्नों और रिपोर्ट निर्माण करते समय आंखों पर int आसान है, और अंतरिक्ष खपत एफके उपयोगों के माध्यम से जोड़ सकती है।

मुझे किसी भी माप को देखने में दिलचस्पी होगी उदा। SQL सर्वर वास्तव में पहचान PK के साथ सम्मिलित-भारी तालिकाओं को संभालता है।

Answer 13

हमारे पास हर जगह हमारे जटिल उद्यम सॉफ्टवेयर में गिड्स हैं। सुचारू रूप से काम करता है।

मेरा मानना ​​है कि Guids पहचानकर्ता के रूप में सेवा करने के लिए अर्थात् अधिक उपयुक्त हैं। जब तक आप उस समस्या का सामना नहीं कर लेते हैं तब तक प्रदर्शन के बारे में अनावश्यक रूप से चिंता करने में कोई बात नहीं है। समयपूर्व अनुकूलन से सावधान रहें।

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