मैंने हमेशा सादगी और (अनुमानित) गति के लिए डेटाबेस में प्राथमिक कुंजी के रूप में लंबे पूर्णांक का उपयोग करना पसंद किया है। लेकिन ऑब्जेक्ट इंस्टेंस के लिए 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 सवाल, ...