यूयूआईडी का उपयोग डेटाबेस पंक्ति पहचानकर्ताओं के रूप में विशेष रूप से वेब ऐप्स में करने पर आपकी राय क्या है?

Question

मैंने हमेशा सादगी और (अनुमानित) गति के लिए, डेटाबेस में प्राथमिक कुंजी के रूप में लंबे पूर्णांक का उपयोग करना पसंद किया है। लेकिन जब वस्तु उदाहरणों के लिए एक REST या रेल की तरह यूआरएल योजना का उपयोग कर, मैं तो ऊपर इस तरह URL के अंत चाहते हैं:

http://example.com/user/783 

और फिर इस धारणा वहाँ भी 782 की आईडी, 781 के साथ उपयोगकर्ताओं को यह है कि, ..., 2, और 1. मान लीजिए कि प्रश्न में वेब ऐप अन्य उपयोगकर्ताओं को प्राधिकरण के बिना अन्य उपयोगकर्ताओं को देखने के लिए पर्याप्त सुरक्षित है, एक सरल अनुक्रमिक रूप से निर्दिष्ट सरोगेट कुंजी भी उदाहरणों की कुल संख्या (लीक " इस से), इस मामले में उपयोगकर्ता, जो विशेषाधिकार प्राप्त जानकारी हो सकती है। (उदाहरण के लिए, मैं स्टैक ओवरफ्लो में उपयोगकर्ता # 726 हूं।)

UUID/GUID एक बेहतर समाधान होगा? तो मैं इस तरह के यूआरएल स्थापित कर सकता था:

http://example.com/user/035a46e0-6550-11dd-ad8b-0800200c9a66 

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

क्या वेब-एड्रेसेबल ऑब्जेक्ट इंस्टेंस के लिए यूयूआईडी लागू करने की लागत और जटिलता का वह लाभ है? मुझे लगता है कि मैं अभी भी जुड़ने के लिए डेटाबेस पीके के रूप में पूर्णांक कॉलम का उपयोग करना चाहता हूं।

यूयूआईडी के डेटाबेस में प्रतिनिधित्व का सवाल भी है। मुझे पता है कि MySQL उन्हें 36-वर्ण तारों के रूप में संग्रहीत करता है। पोस्टग्रेज़ में एक अधिक कुशल आंतरिक प्रतिनिधित्व (128 बिट्स) है, लेकिन मैंने इसे स्वयं नहीं किया है। किसी के भी पास इस के साथ कोई भी अनुभव है?

---

अद्यतन: उन जो सिर्फ URL में उपयोगकर्ता नाम का उपयोग कर के बारे में पूछा के लिए (जैसे, http://example.com/user/yukondude), कि वेब एप्लिकेशन वस्तुओं के zillions के बारे में ऐसे नाम हैं जो अद्वितीय हैं के साथ वस्तु उदाहरणों के लिए ठीक काम करता है, लेकिन क्या है कि वास्तव में केवल संख्या द्वारा पहचाना जा सकता है? ऑर्डर, लेन-देन, चालान, डुप्लिकेट छवि नाम, स्टैक ओवरफ्लो प्रश्न, ...

Answer 1

मैं आपके प्रश्न के वेब पक्ष के बारे में नहीं कह सकता। लेकिन यूयूआईडी एन-स्तरीय अनुप्रयोगों के लिए बहुत अच्छे हैं। पीके पीढ़ी को विकेन्द्रीकृत किया जा सकता है: प्रत्येक ग्राहक टकराव के जोखिम के बिना अपने स्वयं के पीके उत्पन्न करता है। और गति अंतर आम तौर पर छोटा होता है।

सुनिश्चित करें कि आपका डेटाबेस एक कुशल स्टोरेज डाटाटाइप (16 बाइट्स, 128 बिट्स) का समर्थन करता है। कम से कम आप बेस 64 में यूयूआईडी स्ट्रिंग को एन्कोड कर सकते हैं और char (22) का उपयोग कर सकते हैं।

मैंने उन्हें फ़ायरबर्ड के साथ बड़े पैमाने पर उपयोग किया है और अनुशंसा करते हैं।

Answer 2

मैं एक छात्र प्रबंधन प्रणाली के साथ काम करता हूं जो यूयूआईडी को पूर्णांक के रूप में उपयोग करता है। उनके पास एक टेबल है जिसमें अगली अद्वितीय आईडी है।

हालांकि यह संभवतः एक वास्तुशिल्प दृष्टिकोण के लिए एक अच्छा विचार है, यह दैनिक आधार पर कठिन काम करता है। कभी-कभी थोक आवेषण करने की आवश्यकता होती है और यूयूआईडी होने से यह बहुत मुश्किल हो जाता है, आमतौर पर एक सरल चयन के बजाय कर्सर लिखने की आवश्यकता होती है।

Answer 3

मुझे लगता है कि एक GUID का उपयोग करना आपकी स्थिति में बेहतर विकल्प होगा। यह और अधिक जगह लेता है लेकिन यह अधिक सुरक्षित है।

Answer 4

मैं आपको जवाब दे सकता हूं कि SQL सर्वर में यदि आप एक अद्वितीय पहचानकर्ता (GUID) डेटाटाइप का उपयोग करते हैं और मूल्य बनाने के लिए NEWID() फ़ंक्शन का उपयोग करते हैं तो आपको पृष्ठ विभाजन के कारण भयानक विखंडन मिलेगा। इसका कारण यह है कि जब NEWID का उपयोग किया जाता है() उत्पन्न मूल्य अनुक्रमिक नहीं है। एसक्यूएल 2005 ने

अभी भी GUID और int का उपयोग करने का एक तरीका है एक ग्रिड और एक int में एक टेबल होना ताकि ग्रिड int int के लिए नक्शा हो। GUID बाहर से प्रयोग किया जाता है लेकिन जुड़ जाता है और वेब एप्लिकेशन में guids में उदाहरण

457180FB-C2EA-48DF-8BEF-458573DA1C10 1 
9A70FF3C-B7DA-4593-93AE-4A8945943C8A 2 

1 और 2 के लिए डीबी

में पूर्णांक आंतरिक रूप से उपयोग किया जाएगा। यह तालिका बहुत संकीर्ण होगी और

Answer 5

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

एक छोटी आईडी बनाएं जिसे आप यूआरएल में मैप कर सकते हैं, या एक अद्वितीय उपयोगकर्ता नाम सम्मेलन (http://example.com/user/brianly) लागू कर सकते हैं। 37Signals पर लोग शायद आपको वेब ऐप की बात करते समय इस तरह के बारे में चिंता करने के लिए नकल करेंगे।

संयोग से आप आधार मान से पूर्णांक आईडी बनाने शुरू करने के लिए अपने डेटाबेस को मजबूर कर सकते हैं।

Answer 6

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

Answer 7

के बजाय इस तरह यूआरएल:

http://example.com/user/783 

क्यों नहीं:

http://example.com/user/yukondude 

जो मनुष्य के लिए मित्रवत और लीक नहीं करता है कि सूचना के छोटा सा?

Answer 8

आप पंक्ति संख्या से संबंधित एक पूर्णांक का उपयोग कर सकते हैं लेकिन अनुक्रमिक नहीं है। उदाहरण के लिए, आप अनुक्रमिक आईडी के 32 बिट्स ले सकते हैं और उन्हें एक निश्चित योजना के साथ पुनर्व्यवस्थित कर सकते हैं (उदाहरण के लिए, बिट 1 बिट 6 हो जाता है, बिट 2 बिट 15 हो जाता है, आदि ..)।
यह एक द्विपक्षीय एन्क्रिप्शन होगा, और आप सुनिश्चित होंगे कि दो अलग-अलग आईडी में हमेशा अलग-अलग एन्क्रिप्शन होंगे।
यह निश्चित रूप से डीकोड करना आसान होगा, अगर कोई पर्याप्त आईडी उत्पन्न करने और स्कीमा प्राप्त करने में समय लेता है, लेकिन, अगर मैं आपकी समस्या को सही ढंग से समझता हूं, तो आप केवल जानकारी को आसानी से नहीं देना चाहते हैं।

Answer 9

मुझे लगता है कि यह इन मुद्दों कि अर्ध धार्मिक बहस का कारण में से एक है, और इसके लगभग बारे में बात करना व्यर्थ। मैं केवल वही कहूंगा जो आप पसंद करते हैं। 99% प्रणालियों में इससे कोई फर्क नहीं पड़ता कि आप किस प्रकार की कुंजी का उपयोग करते हैं, इसलिए दूसरे पर एक तरह का उपयोग करने के लाभ (अन्य पदों में बताए गए) कभी भी एक मुद्दा नहीं होंगे।

Answer 10

हम GUIDs को हमारे सभी तालिकाओं के लिए प्राथमिक कुंजी के रूप में उपयोग करते हैं क्योंकि यह एमएस एसक्यूएल सर्वर प्रतिकृति के लिए रोउल्श के रूप में दोगुना हो जाता है। यह बहुत आसान बना देता है जब ग्राहक अचानक दुनिया के दूसरे हिस्से में एक कार्यालय ...

Answer 11

यह भी कि तुम क्या आपके आवेदन के लिए के बारे में परवाह पर निर्भर करता है खोलता है।एन-स्तरीय ऐप्स के लिए GUIDs/UUID लागू करने के लिए आसान हैं और विभिन्न डेटाबेस के बीच बंदरगाह आसान है। इंटीजर कुंजियों का उत्पादन करने के लिए कुछ डेटाबेस क्रमशः अनुक्रम वस्तु का समर्थन करते हैं और कुछ को अनुक्रम तालिका के कस्टम निर्माण की आवश्यकता होती है।

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

Answer 12

आपके यूआरआई के साथ आपकी प्राथमिक कुंजी क्यों जोड़े?

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

यहां जोड़ा गया लाभ यह है कि अब आपके पास वास्तव में एक अच्छी यूआरएल संरचना है, जो एसईओ के लिए अच्छा है। स्पष्ट रूप से एक लेनदेन के लिए यह एक अच्छी बात नहीं है, लेकिन स्टैक ओवरफ्लो जैसे कुछ के लिए, यह महत्वपूर्ण है (ऊपर यूआरएल देखें ...)। विशिष्टता प्राप्त करना मुश्किल नहीं है। यदि आप वास्तव में चिंतित हैं, तो किसी तालिका के अंदर कहीं भी स्लग का हैश स्टोर करें, और सम्मिलन से पहले एक लुकअप करें।

संपादित करें: स्टैक ओवरफ्लो मेरे द्वारा वर्णित सिस्टम का काफी उपयोग नहीं करता है, नीचे लड़के की टिप्पणी देखें।

Answer 13

जब तक आप कुशल भंडारण के साथ एक डीबी प्रणाली का उपयोग, HDD सस्ते इन दिनों वैसे भी है ...

मैं जानता हूँ कि GUID का हो सकता है ab * tch कुछ समय के साथ काम करते हैं और से हालांकि कुछ क्वेरी भूमि के ऊपर के साथ आने के लिए एक सुरक्षा परिप्रेक्ष्य वे एक उद्धारक हैं।

अस्पष्टता से सुरक्षा सोचना वे अस्पष्ट यूआरआई बनाते समय अच्छी तरह फिट बैठते हैं और तालिका, रिकॉर्ड और कॉलम परिभाषित सुरक्षा के साथ सामान्यीकृत डीबी का निर्माण करते हैं, आप GUID के साथ गलत नहीं जा सकते हैं, पूर्णांक आधारित आईडी के साथ ऐसा करने का प्रयास करें।

Answer 14

मैंने वास्तविक वेब ऐप्स दोनों में कोशिश की है।

मेरी राय यह है कि यह पूर्णांक का उपयोग करना बेहतर है और संक्षिप्त, समझदार यूआरएल है।

डेवलपर के रूप में, यह अनुक्रमिक पूर्णांक देखने में थोड़ा भयानक लगता है और यह जानकर कि कुल रिकॉर्ड गिनती के बारे में कुछ जानकारी लीक हो रही है, लेकिन ईमानदारी से - अधिकांश लोगों को शायद परवाह नहीं है, और वह जानकारी कभी भी महत्वपूर्ण नहीं रही है मेरे व्यवसाय

लंबे बदसूरत यूयूआईडी यूआरएल होने से मुझे सामान्य उपयोगकर्ताओं के लिए एक अधिक मोड़ लग रहा है।