मुझे पता है कि सरोगेट प्राथमिक कुंजी आमतौर पर प्राकृतिक प्राथमिक कुंजी पर अनुशंसा की जाती है, लेकिन जब उपयोगकर्ता नामों की बात आती है तो सरोगेट प्राथमिक कुंजी के पक्ष में कोई तर्क होता है?क्या उपयोगकर्ता नाम प्राथमिक कुंजी के लिए वैध उम्मीदवार हैं?
यदि आप डुप्लिकेट उपयोगकर्ता नाम प्राप्त नहीं करना चाहते हैं, तो UNIQUE constraint बनाएं।
क्या होगा अगर DWong1145 अपना उपयोगकर्ता नाम बदलना चाहता है? क्या आप सभी डेटाबेस संबंध UPDATE CASCADE बनेंगे?
ग्राहक दृष्टिकोण से, आप शर्त लगाते हैं। मैं नहीं चाहता कि मेरा उपयोगकर्ता नाम DWong1145 हो।
नहीं, आपको चाहिए केवल उपयोग उपयोगकर्ता नाम एक अद्वितीय कुंजी/निरंतर के रूप में। उपयोगकर्ता नाम बदला जा सकता है, बस और उदाहरण: यह एक ट्रेडमार्क हो सकता है और मालिक आपको इसे छोड़ने का अनुरोध करता है।
थोड़ा सा लगता है;) आप * सही हैं हालांकि। मैं उन प्रणालियों से नफरत करता हूं जिन पर आप अपना उपयोगकर्ता नाम नहीं बदल सकते - हालांकि, ओपी ने टिप्पणियों में कहा कि वह इसे बदलना नहीं चाहता है, इसलिए ... –
यह कुछ समझ में एक अच्छा उम्मीदवार है, हालांकि आपको यह विचार करना होगा कि क्या आप वास्तव में ऐसा करना चाहते हैं। उदाहरण के लिए, आपके पास एक निश्चित उपयोगकर्ता नाम वाला उपयोगकर्ता है, तो उपयोगकर्ता को "हटाया गया" (या हटाए गए के रूप में चिह्नित) हो जाता है। इसलिए, वास्तव में एक ही उपयोगकर्ता नाम के साथ किसी अन्य उपयोगकर्ता को बनाने की अनुमति न देने का कोई कारण नहीं है, लेकिन यह पहले से ही "लिया गया" है, क्योंकि यह प्राथमिक कुंजी है।
प्राथमिक कुंजी के रूप में स्ट्रिंग रखने का एक बड़ा नुकसान, भले ही यह उपयोगकर्ता नाम या कुछ और हो, यह भी है कि तालिका का संदर्भ देने वाले सभी विदेशी कुंजी कॉलम भी स्ट्रिंग्स होंगे, जो दोनों धीमे और अधिक जगह बर्बाद कर सकते हैं।
इसे धीमा नहीं होना चाहिए। अच्छा डेटाबेस इंजन किसी भी स्ट्रिंग मान पूर्व-हैश हो सकता है। इसके शीर्ष पर, प्राकृतिक चाबियों का उपयोग करने से शायद एप्लिकेशन में कई जुड़ने की ज़रूरत खत्म हो जाएगी, इसलिए प्रश्नों को तेज़ी से बनाते हैं। मैं स्वीकार करता हूं कि प्राकृतिक चाबियाँ आम तौर पर अधिक जगह का उपभोग करती हैं लेकिन ईमानदारी से, अंतरिक्ष सस्ता और भरपूर है। –
मेरा प्रश्न प्रमाणीकरण प्रणाली के संदर्भ में है जो नहीं होगा उपयोगकर्ता नाम परिवर्तन की अनुमति दें। मुझे इसका उल्लेख करना चाहिए था। –
@ इमानुइल - जुरासिक पार्क में जेफ गोल्डब्लम को उद्धृत करने के लिए, "जीवन एक रास्ता पाता है।" अगर आपको कुछ दिन अपने उपयोगकर्ता नाम बदलने की ज़रूरत है, तो आप अभी इस पल पर पछतावा कर रहे हैं ... –
"सूचना 'को कुंजी के रूप में उपयोग नहीं किया जाना चाहिए;' डेटा' कर सकते हैं"; 'डेटा' को बदलने की जरूरत नहीं है, जैसे कि हमेशा किसी प्रोग्राम द्वारा समझा जाना चाहिए। क्या होगा यदि मैं SO को कॉल करता हूं और अपने उपयोगकर्ता _id_ को बदलने के लिए कहता हूं? मैं ऐसा नहीं कर सकता, लेकिन मैं अपना उपयोगकर्ता _name_ बदल सकता हूं। –