क्या प्राथमिक कुंजी के रूप में विदेशी कुंजी होना ठीक है?

Question

मेरे पास टेबल "उपयोगकर्ता" (उपयोगकर्ता नाम, पासवर्ड) और तालिका "प्रोफ़ाइल" है (प्रोफ़ाइल आईडी, लिंग, डेटफॉर्थ, ...)। वर्तमान में मैं इस दृष्टिकोण का उपयोग कर रहा हूं: प्रत्येक प्रोफाइल रिकॉर्ड में "userId" नाम का एक फ़ील्ड है जो विदेशी कुंजी के रूप में होता है जो उपयोगकर्ता तालिका से लिंक होता है। जब कोई उपयोगकर्ता पंजीकृत होता है, तो उसका प्रोफाइल रिकॉर्ड स्वचालित रूप से बनाया जाता है। मैं अपने मित्र सुझाव के साथ उलझन में हूं: "userId" फ़ील्ड को विदेशी और प्राथमिक कुंजी के रूप में रखने और "प्रोफ़ाइल आईडी" फ़ील्ड को हटाएं। कौन सा दृष्टिकोण बेहतर है?

Answer 1

विदेशी कुंजी लगभग हमेशा से रहे हैं जो उन्हें प्राथमिक कुंजी के रूप में अनुपयुक्त होता "डुप्लिकेट, की अनुमति दें"।

इसके बजाय, उस फ़ील्ड को खोजें जो तालिका में प्रत्येक रिकॉर्ड को विशिष्ट रूप से पहचानता है, या प्राथमिक कुंजी के रूप में कार्य करने के लिए एक नया फ़ील्ड (या तो एक ऑटो-वृद्धिशील पूर्णांक या GUID) जोड़ें।

इसका एकमात्र अपवाद एक-से-एक संबंध के साथ तालिकाओं है, जहां लिंक की गई तालिका की विदेशी कुंजी और प्राथमिक कुंजी एक और समान है।

Answer 2

मैं ऐसा नहीं करूँगा। मैं profileID तालिका Profile

के रूप में प्राथमिक कुंजी रखेंगे एक विदेशी कुंजी दो तालिकाओं

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

http://www.aisintl.com/case/primary_and_foreign_key.html

Answer 3

प्राथमिक कुंजी हमेशा अनूठी होने की आवश्यकता होती है, यदि तालिका एक-से-कई रिश्ते हैं तो गैर-अद्वितीय मानों को अनुमति देने की आवश्यकता है। यदि एक-एक-एक रिश्ते से जुड़ा हुआ है, तो एक से अधिक रिश्तों को नहीं, तो प्राथमिक कुंजी के रूप में विदेशी कुंजी का उपयोग करना बिल्कुल ठीक है। यदि आप एक ही उपयोगकर्ता रिकॉर्ड चाहते हैं कि 1 से अधिक संबंधित प्रोफाइल रिकॉर्ड होने की संभावना हो, तो एक अलग प्राथमिक कुंजी के साथ जाएं, अन्यथा आपके पास जो कुछ है उसके साथ चिपके रहें।

Answer 4

यह व्यापार और प्रणाली पर निर्भर करता है।

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

Answer 5

इसे आम तौर पर एक से एक रिश्ते के लिए बुरी आदत माना जाता है। ऐसा इसलिए है क्योंकि आप केवल एक तालिका में प्रदर्शित डेटा प्राप्त कर सकते हैं और एक ही परिणाम प्राप्त कर सकते हैं।

हालांकि, ऐसे कई उदाहरण हैं जहां आप तालिका में इन परिवर्तनों को संदर्भित करने में सक्षम नहीं हो सकते हैं। इस उदाहरण में प्राथमिक कुंजी के रूप में विदेशी कुंजी का उपयोग करने में कोई समस्या नहीं है। यह एक समग्र कुंजी रखने में मदद कर सकता है जिसमें एक ऑटो वृद्धिशील अद्वितीय प्राथमिक कुंजी और विदेशी कुंजी शामिल है।

मैं वर्तमान में ऐसे सिस्टम पर काम कर रहा हूं जहां उपयोगकर्ता लॉग इन कर सकते हैं और ऐप के साथ उपयोग करने के लिए पंजीकरण कोड उत्पन्न कर सकते हैं। कारणों से मैं नहीं जाऊंगा मैं उपयोगकर्ताओं की तालिका में आवश्यक कॉलम जोड़ने में असमर्थ हूं। इसलिए मैं कोड तालिका के साथ एक से एक मार्ग पर जा रहा हूं।

Answer 6

हाँ, एक विदेशी कुंजी उन तालिकाओं

Answer 7

हाँ, यह एक प्राथमिक कुंजी एक विदेशी कुंजी किया जा रहा है करने के लिए कानूनी है के बीच एक रिश्ता करने के लिए एक के मामले में एक प्राथमिक कुंजी हो सकता है। यह एक दुर्लभ निर्माण है, लेकिन यह इसके लिए लागू होता है:

• 1: 1 संबंध। अलग-अलग अनुमतियों और विशेषाधिकारों के कारण केवल दो टेबलों को विलय नहीं किया जा सकता है, केवल तालिका स्तर पर लागू होते हैं (2017 तक, ऐसा डेटाबेस अजीब होगा)।

• 1: 0..1 संबंध। उपयोगकर्ता प्रकार के आधार पर प्रोफ़ाइल मौजूद हो सकती है या नहीं भी हो सकती है।

• प्रदर्शन एक मुद्दा है, और डिज़ाइन एक विभाजन के रूप में कार्य करता है: प्रोफ़ाइल तालिका को शायद ही कभी एक्सेस किया जाता है, अलग डिस्क पर होस्ट किया जाता है या उपयोगकर्ता तालिका की तुलना में एक अलग sharding नीति है। यदि अंडरलाइनिंग स्टोरेज कॉलमर है तो समझ में नहीं आता है।