चौराहे की मेज बनाने के बजाय एक अशक्त विदेशी कुंजी का उपयोग करने का नुकसान

Question

कहें कि मेरे पास निम्नलिखित ईआर चित्र हैं:

अब अगर मैं संबंध में प्रतिनिधित्व की एक विदेशी कुंजी का उपयोग कर Schoolमें Student, मैं हो सकता था NULLमानों (क्योंकि एक Student एक के हैं की आवश्यकता नहीं है Schoolउदाहरण के लिए),:

इसलिए सही तरीका (मैंने जो पढ़ा है, उसके आधार पर) उदाहरण के लिए, रिश्ते का प्रतिनिधित्व करने के लिए एक प्रतिच्छेदन तालिका बनाना है:

इस तरह, कोई भी NULLमान तालिका में मौजूद नहीं हो सकता है School_has_Student।

लेकिन चौराहे की मेज बनाने के बजाय एक अशक्त विदेशी कुंजी का उपयोग करने के नुकसान क्या हैं?

---

संपादित करें:

मैं चुना है गलती से ( school_id, student_id) के लिए प्राथमिक कुंजी होने की School_has_Studentमेज, जो रिश्ते बना कई-से-अनेक। सही प्राथमिक कुंजी होनी चाहिए student_id:

Comments

कोई "सही" तरीका नहीं है। वहाँ सिर्फ तरीका है कि आपकी आवश्यकताओं के लिए सबसे अच्छा है।

— 16

मैं झूठे आधार के बारे में डॉक्टर से सहमत हूं, लेकिन शायद यह अभी भी जवाब देने के लिए पर्याप्त स्पष्ट है?

— मेटाफ़ाइट

एक गलत आधार है, लेकिन अंतर को सीधा करना और समझाना काफी आसान है।

मैंने अपने करीबी वोट को वापस ले लिया, लेकिन वाक्य "तो सही तरीका (जो मैंने पढ़ा है उसके आधार पर) रिश्ते का प्रतिनिधित्व करने के लिए एक प्रतिच्छेदन तालिका बनाने के लिए है" मुझे यह आभास देता है कि आपको हमें बताना चाहिए कि किस स्ट्रगल स्रोत ने आपको यह बताया है " सही तरीका। मैंने पहले हर पाठ्य पुस्तक में, 1: n संबंधों के लिए विहित तरीका एक एकल विदेशी कुंजी है। या आपने कुछ गलत समझा?

— डॉक्टर ब्राउन

@ डॉक ब्राउन मुझे याद नहीं है कि मैंने इसे कहां पढ़ा है, लेकिन मुझे यकीन है कि यह कहता है कि एक चौराहा टेबल सही तरीका था। वैसे भी, क्या आप मुझे एक पुस्तक का नाम दे सकते हैं जो कहती है कि एक: विदेशी संबंध (: 1 पक्ष पर वैकल्पिक भागीदारी के साथ) का प्रतिनिधित्व एक ही विदेशी कुंजी का उपयोग करके किया जाना चाहिए, मुझे यह पढ़ने में दिलचस्पी है कि वे इस विषय के बारे में क्या कहते हैं।

— टॉम

Answer 1

दो मॉडल अलग-अलग रिश्तों का प्रतिनिधित्व करते हैं।

जॉइन टेबल का उपयोग करके, आप कई-से-कई संबंधों को मॉडलिंग कर रहे हैं।

एक साधारण विदेशी कुंजी का उपयोग करके, आप एक-से-कई संबंधों को मॉडलिंग कर रहे हैं।

एक अशक्त विदेशी कुंजी का नुकसान कई-से-कई के रूप में रिश्ते को मॉडल करने में असमर्थ हो रहा है, यदि आप इसे पूरा करने की कोशिश कर रहे हैं।

---

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

छात्र तालिका को विभाजित करके, आप दूसरी तालिका को वैकल्पिक बना रहे हैं क्योंकि दूसरी तालिका में रिकॉर्ड की आवश्यकता नहीं है। जो एक ऐसे क्षेत्र के समान है जिसे सेट करने की आवश्यकता नहीं है क्योंकि यह अशक्त हो सकता है।

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

यदि आप जुड़ने के बारे में चिंतित हैं, तो चिंता न करें। अशक्त क्षेत्रों के साथ काम में कैसे जुड़ता है, इसके लिए अच्छी तरह से परिभाषित शब्दार्थ हैं। एक एकल तालिका का उपयोग करके, आप तीन के बजाय दो तालिकाओं में शामिल हो सकते हैं।

Comments

इसलिए अगर मैं एक से कई संबंधों (: 1 पक्ष पर वैकल्पिक भागीदारी के साथ) को मॉडलिंग कर रहा हूं, तो मुझे इस तथ्य के बावजूद एक विदेशी कुंजी का उपयोग करना चाहिए कि इसमें NULLमान हो सकते हैं ?

— टॉम

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

मैंने अपने प्रश्न का संपादन किया। मैंने केवल तालिका student_idमें एक प्राथमिक कुंजी School_has_Studentबनाई, जिसने रिश्ते को एक-से-कई के रूप में रखा। एक विदेशी कुंजी का उपयोग करने पर इस पद्धति में क्या कमियां हैं?

— टॉम

@ क्या मैंने अपना उत्तर संपादित किया।

Answer 2

आपने ऊपर टिप्पणी में लिखा है:

"फंडामेंटल ऑफ डेटाबेस सिस्टम" पुस्तक [...] कहती है [...] कि एक चौराहे की मेज का उपयोग करने की सिफारिश की जाती है यदि विदेशी कुंजी कॉलम में बहुत सारे मान हैं (उदाहरण के लिए: यदि 98% कर्मचारी हैं एक विभाग का प्रबंधन न करें)

जब विदेशी कुंजी कॉलम में बहुत सारे NULL मान होते हैं, तो आपके कार्यक्रमों को प्रत्येक रिकॉर्ड प्रक्रिया के लिए इस खाली कॉलम से निपटना होगा। कॉलम संभवतः कुछ डिस्क स्थान पर कब्जा कर लेगा, भले ही 98% मामलों में इसके खाली होने पर, रिश्ते को क्वेरी करने का मतलब है उस कॉलम को क्वेरी करना जो आपको अधिक नेटवर्क ट्रैफ़िक देता है, और यदि आप एक ORM का उपयोग कर रहे हैं जो आपको अपने टेबल से कक्षाएं उत्पन्न करता है, तो आपके प्रोग्राम आवश्यकता से अधिक क्लाइंट की ओर से अधिक स्थान की आवश्यकता होगी। एक चौराहे की मेज का उपयोग करने से बचा जाता है, केवल लिंक रिकॉर्ड आवश्यक होंगे जहां समकक्ष विदेशी कुंजी अन्यथा पूरी नहीं होगी।

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

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

एक टिप्पणी करने के लिए एक साइड नोट के रूप में: उपरोक्त कथन सिर्फ यह अनुमान लगाने की कोशिश कर रहा है कि "फंडामेंटल ऑफ डेटाबेस सिस्टम" के लेखक ने उसकी सिफारिश को ध्यान में रखा था, मुझे लगता है कि वह ज्यादातर प्रणालियों के लिए मान्य एक सामान्य, सामान्य बयान दे रहा था। कुछ डेटाबेस में "स्पार्स कॉलम" जैसे अन्य संभावित अनुकूलन हैं जो एक चौराहे की मेज के उपयोग को और भी अधिक अप्रचलित बनाते हैं।

तो वह सिफारिश गलत नहीं है। पुस्तक आपको {0,1}:nसामान्य रूप से रिश्तों के लिए प्रतिच्छेदन तालिका पसंद करने के लिए नहीं कहती है , या - जैसा कि आपने लिखा है - कि यह "सही तरीका" है। इस तरह के अनुकूलन का उपयोग करें जो आपके कार्यक्रमों को केवल तभी और अधिक जटिल बना देगा जब आपको वास्तव में उनकी आवश्यकता होगी।

Comments

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

— गार्डनहेड

@gardenhead: आपको क्या लगता है कि यह "संभावना से अधिक" है?

— डॉक्टर ब्राउन

तथ्य यह है कि डेटाबेस दशकों से आसपास रहे हैं और अत्यधिक अनुकूलित हैं क्योंकि वे अधिकांश बुनियादी ढांचे का एक महत्वपूर्ण घटक हैं।

— गार्डेनहेड

@gardenhead: मुझे लगता है कि आप मुझसे अधिक अनुचित धारणा बना रहे हैं। फिर भी, मेरा संपादन देखें।

— डॉक्टर ब्राउन

Answer 3

वैचारिक मॉडल इस तरह दिखेगा, जिसे कम कहना बहुत अपरंपरागत है:

भौतिक मॉडल इस तरह दिखाई देगा, जो कम कहने के लिए भ्रामक है (लोग सोचेंगे कि यह एम: एम है जब तक वे करीब से नहीं देखते):

मेरा सुझाव:

यदि आपको पसंद है, तो कई कॉलम (एफके या अन्यथा), जो कि अधिकांश छात्रों पर लागू नहीं होते हैं, टेबल को 1: 1 रिले के साथ भूमिका तालिकाओं में अलग करें। लेकिन ऐसा नहीं है क्योंकि वे एफके हैं, यह इसलिए है क्योंकि कॉलम अधिकांश पंक्तियों पर लागू नहीं होते हैं।

अन्यथा , अशक्त FK एक डेटाबेस का एक सामान्य हिस्सा है और ज्वाइन टेबल आमतौर पर M: M रिले के लिए हैं।

1: 1 रिले का सामान्य उपयोग रोल टेबल वाले कॉलम के लिए होता है जो केवल तभी लागू होता है जब इकाई एक निश्चित प्रकार की होती है, और प्रदर्शन या भंडारण विचारों के लिए BLOB कॉलम निकालते हैं। FK में एवलोडिंग शून्य मान इसके लिए एक सामान्य उपयोग नहीं है।

Answer 4

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

1) छात्र का विद्यालय (यदि कोई हो) अज्ञात है (यह 'अशक्त' का मानक अर्थ है - मूल्य अज्ञात है)

2) यह ज्ञात है कि छात्र के पास स्कूल है या नहीं, और उनके पास कोई नहीं है

यदि आप अशक्त के मानक अर्थ का उपयोग करते हैं, तो आप अपने विदेशी कुंजी मॉडल में "छात्र का कोई विद्यालय नहीं है" का प्रतिनिधित्व कैसे करेंगे। उस स्थिति में, आपको शायद "स्कूल नहीं" प्रविष्टि बनानी होगी, क्योंकि यह स्कूल की तालिका में अपना आईडी है। (आदर्श नहीं)

Comments

"फंडामेंटल ऑफ डेटाबेस सिस्टम" पुस्तक में उल्लेख है कि इसके लिए 3 व्याख्याएं हैं NULL, इसका मतलब हो सकता है: 1) अज्ञात मूल्य। 2) अनुपलब्ध या रोक दिया गया मान। 3) लागू विशेषता नहीं (मुझे लगता है कि यह व्याख्या का मतलब है कि आप NULLएक विदेशी कुंजी के लिए निर्दिष्ट कर सकते हैं )।

— टॉम

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

— ब्रैड थॉमस

तो क्या आप सुझाव दे रहे हैं कि मुझे एक अशक्त विदेशी कुंजी का उपयोग करने के बजाय एक चौराहे की मेज बनानी चाहिए?

— टॉम

@ हां, मेरा मानना ​​है कि इस मामले में बेहतर है

— ब्रैड थॉमस

@ ब्रैडटॉमस - चौराहे की मेज का उपयोग करते समय एक ही अस्पष्टता से बचने के लिए, क्या आप केस 2 का प्रतिनिधित्व करेंगे (यह ज्ञात है कि छात्र के पास कोई स्कूल नहीं है) एक पूर्ण स्कूल_आईडी के साथ चौराहे की मेज में रिकॉर्ड है?

— andrew

Answer 5

डेटाबेस टेबल में यह अच्छी चीज है जिसे अड़चन कहा जाता है। इसलिए चौराहे की तालिका बनाना बहुत आसान है, जिससे प्रत्येक छात्र तालिका में केवल 1 दिखाई देता है, लेकिन उस तालिका में कई स्कूल हैं। प्रभावी रूप से आपको ए

थ्योरी अच्छी है, लेकिन अंत में आप अपने डेटाबेस को उन प्रश्नों के बाद मॉडल करने जा रहे हैं जो आप पूछ रहे हैं।

यदि आप प्रश्न के साथ अक्सर सवाल करना चाहते हैं: "कौन से छात्र मेरे स्कूल में हैं" क्या आप वास्तव में पूरे छात्रों की तालिका को क्वेरी करना चाहते हैं या एक आसान चौराहा तालिका है।

डेटाबेस में: आपके द्वारा पूछे गए प्रश्नों के लिए ऑप्टिमाइज़ करें।

Answer 6

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

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

इसलिए जैसा कि आप देख सकते हैं, यह काफी विशिष्ट मामला है, और जैसा कि अन्य ने उल्लेख किया है, ज्यादातर बार आप सभी NULLमूल्यों के साथ पूरी तरह से ठीक होंगे । यह वास्तव में आपके मॉडल की विशिष्ट आवश्यकताओं पर निर्भर करता है।

Answer 7

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

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