क्या कई टेबल्स में से कई को प्राथमिक कुंजी चाहिए?

Question

यदि मेरे पास दो ऑब्जेक्ट्स हैं जिनमें कई से अधिक रिश्तों हैं, तो मैं आम तौर पर उन दोनों को जोड़ने के लिए कई डेटाबेस के साथ अपने डेटाबेस स्कीमा में मॉडल करता हूं। लेकिन क्या कई से अधिक टेबल (या "टेबल में शामिल हों") की अपनी प्राथमिक कुंजी (पूर्णांक ऑटो-इंक्रिमेंटेड) होनी चाहिए?

उदाहरण के लिए, मेरे पास टेबल ए और बी हो सकता है, प्रत्येक आईडी के साथ, और A_B नामक एक तालिका जिसमें एक विदेशी कुंजी ट्यूपल (ए_आईडी, बी_आईडी) हो। लेकिन क्या एबी के पास प्राथमिक कुंजी ऑटो-वर्धित आईडी कॉलम होना चाहिए, या नहीं?

इसे जोड़ने के फायदे और नुकसान क्या हैं? मैं व्यक्तिगत रूप से कई से जुड़ने के लिए प्राकृतिक कुंजी पसंद करता हूं। लेकिन प्राथमिक कुंजी जोड़ने का क्या अतिरिक्त लाभ होगा?

Answer 1

मैं सब कुछ Oded

को छोड़कर कहा से सहमत "यह काफी एक विदेशी कुंजी के रूप में या तो नहीं किया जा सकता।"

इस मामले में यह एक अपने जहर लेने है में, मानचित्रण तालिका बिल्कुल एक माता पिता हो सकता है, यह एक multicolumn FK या नहीं का उपयोग कर बच्चे की सिर्फ बात है।

कार और रंग का एक साधारण मामला लें। प्रत्येक वर्ष ऑटो निर्माताओं के रंगों का एक निश्चित फूस होता है और प्रत्येक मॉडल केवल उन रंगों की सीमित संख्या में आता है। कई - कई :: कारों के मॉडल के लिए रंग

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

तो क्या आपके पास एक बहुआयामी एफके होगा और मॉडलआईडी और रंगीन दोनों पर बने पीके को इंगित करें या क्या आप एक कॉलम एफके चाहते हैं?

अपना जहर उठाओ।

संपादित

लेकिन अगर यह कुछ का जनक नहीं है, कोई तालिका एक किराए कुंजी की जरूरत है।

Answer 2

ऐसी सरोगेट कुंजी ओवरहेड को छोड़कर कुछ भी नहीं जोड़ती है।

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

का विस्तार करने के लिए:

आवेदन में, इस कुंजी अर्थहीन हो जाएगा और अप्रयुक्त रहेगा।

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

इसे उचित रूप से विदेशी कुंजी के रूप में उपयोग नहीं किया जा सकता है।

Answer 3

यह वास्तव में कुछ भी उपयोगी नहीं प्रदान करता है। एक कुंजी के उद्देश्य को ध्यान में रखें, जिसे विशिष्ट रूप से "कुछ" का संदर्भ देना है। इस तरह की एक एसोसिएशन टेबल स्वयं "कुछ" नहीं है बल्कि दो अन्य "somethings" के लिए दृढ़ता संरचना है जो पहले से ही चाबियाँ हैं। दृढ़ता माध्यम (डेटाबेस) के बाहर इसका कोई अर्थ नहीं है और वास्तव में अस्तित्व में नहीं होना चाहिए या ज्ञात नहीं होना चाहिए (जैसे कि व्यवसाय डोमेन में), इसलिए इसे कभी भी संदर्भित करने का कोई कारण नहीं होना चाहिए इसकी अपनी आईडी

Answer 4

मैंने इसे दोनों तरीकों से किया है। कभी-कभी सड़क के नीचे एक सुविधा जोड़ने के लिए फायदेमंद होता है। उदाहरण के लिए, यदि कभी ऐसा समय होता है कि तालिका में एक पंक्ति में केवल 2 आईडी की तुलना में कुछ भी शामिल होगा। यदि आपके पास अंतरिक्ष की कमी नहीं है तो मैं वहां पर एक डाल दूंगा क्योंकि यह चोट नहीं पहुंचा सकता है। कभी-कभी यह ओआरएम टूल्स जैसे हाइबरनेट या एडीओ.NET में हस्तक्षेप कर सकता है लेकिन यह मामूली है।

तो इसे समेटने के लिए ... PROS 1. संभावित भावी विकास की अनुमति देता है।

CONS 1. स्पेस 2. कुछ ओआरएम उपकरण को भ्रमित करता है।

Answer 5

शब्द "जॉइन टेबल" शब्द का प्रयोग अक्सर किया जाता है लेकिन मुझे नहीं लगता कि मैंने इसे कभी भी सही ढंग से परिभाषित या समझाया है। व्यक्तिगत रूप से मैं उस शब्द का उपयोग करने से बचता हूं। जैसा कि मैं इसे समझता हूं, "तालिका में शामिल होने" का मतलब है किसी भी तालिका में दो विदेशी कुंजी (या संभवतः दो से अधिक?)।

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