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

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

http://example.com/user/783

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

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

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

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

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

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


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

0
ro fr bn

14 उत्तर

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

0
जोड़ा

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

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

0
जोड़ा

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

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

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

0
जोड़ा
@dah प्रश्नकर्ता प्रश्न में यूआरएल के भीतर इसका उपयोग उल्लेख करता है।
जोड़ा लेखक Brian Lyttle, स्रोत
यह अपरिहार्य है, आपको यूआरएल में यूयूआईडी दिखाने की जरूरत नहीं है।
जोड़ा लेखक davidahines, स्रोत

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

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

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

0
जोड़ा
बेस 64? यदि आपके पास UUID के लिए मूल डेटा प्रकार नहीं है, तो डैश ड्रॉप करें और बाइट (32) में चिपकाएं। जब आपको UUID की आवश्यकता होती है तो यह बेस 64 से / एन्कोडिंग / डिकोडिंग से अधिक तेज़ होगा।
जोड़ा लेखक CMircea, स्रोत

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

http://example.com/user/783

क्यों नहीं है:

http://example.com/user/yukondude

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

0
जोड़ा

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

0
जोड़ा

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

0
जोड़ा

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

0
जोड़ा
यह अचूक साक्ष्य है कि गणितीय सिद्धांत का समर्थन करता है जो पूर्णांक में शामिल होने और अनुक्रमणित करने से लंबे (आईएसएच) तारों से तेज़ होगा।
जोड़ा लेखक Adam Tuttle, स्रोत
यह भी एक जवाब कैसे है।
जोड़ा लेखक davidahines, स्रोत
यदि आप इसे और कहां देखते हैं, तो कुछ और विशिष्ट जानकारी प्रदान कर सकते हैं, यह सहायक होगा। डीबी / टेबल का आकार? डीबी बैकएंड? एक्सेस पैटर्न (क्वेरी कैसा दिखता है) ... आदि?
जोड़ा लेखक Garen, स्रोत

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

GUID और int का उपयोग करने का एक तरीका यह है कि एक तालिका में एक guid और int होना चाहिए ताकि guid नक्शे int। ग्रिड बाहरी रूप से उपयोग किया जाता है लेकिन आंतरिक रूप से डीबी में आंतरिक रूप से उपयोग किया जाता है

उदाहरण के लिए

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

1 और 2 का उपयोग वेब ऐप में जॉइन और ग्रिड में किया जाएगा। यह तालिका बहुत संकीर्ण होगी और क्वेरी करने के लिए बहुत तेज़ होना चाहिए

0
जोड़ा

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

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

0
जोड़ा

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

0
जोड़ा
मुझे नहीं लगता कि सवाल का इरादा यूयूआईडी का उपयोग करने का एक सुरक्षित तरीका था। जहां तक ​​मुझे पता चला है कि विषय उस निर्णय के व्यावहारिक रूप से ramifications थे। और आपकी योजना कोई सुरक्षा नहीं जोड़ती है और सीपीयू चक्रों का अपशिष्ट है!
जोड़ा लेखक Patrick Cornelissen, स्रोत

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

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

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

edit: Stackoverflow doesn't quite use the system I describe, see Guy's comment below.

0
जोड़ा
आईडी पर स्टैक ओवरफ़्लो इंडेक्स और स्लग नहीं। पृष्ठ के शीर्ष पर स्लॉग बदलने का प्रयास करें और एंटर दबाएं। यह 301 आपको आईडी (5 9 4 9) के आधार पर इस पृष्ठ के लिए कैनोलिक यूआरएल पर रीडायरेक्ट करेगा और स्लग को अनदेखा करेगा। सर्वर पर, यह स्लग को संग्रहीत / जेनरेट किए गए स्लग से तुलना करता है। यदि ऐसा नहीं है तो यह 301 लौटाता है। हालांकि यह पता चलता है कि आईडी (5 9 4 9) पर लुकअप करके।
जोड़ा लेखक Guy, स्रोत
स्पष्टीकरण के लिए धन्यवाद!
जोड़ा लेखक Jonathan Arkell, स्रोत

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

मुझे पता है कि GUID कुछ समय के साथ काम करने के लिए बी * टीएच हो सकता है और कुछ प्रश्न ओवरहेड के साथ आ सकता है हालांकि सुरक्षा परिप्रेक्ष्य से वे एक उद्धारकर्ता हैं।

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

0
जोड़ा

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

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

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

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

0
जोड़ा
इस राय के लिए धन्यवाद। मैंने यूयूआईडी का उपयोग प्राथमिक कुंजी के रूप में अपने सभी संभावित नुकसान के साथ दिनों तक किया जब तक मुझे एहसास हुआ कि मेरे मामले में एकमात्र लाभ (छुपा व्यापार जानकारी) इसके लायक नहीं है।
जोड़ा लेखक Jan-Philip Gehrcke, स्रोत