तीसरी तालिका को ब्रिज टेबल से कई से कई एसोसिएशन में जोड़ना

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

विकल्प एक है:TEACHER . के बीच के साधारण चौराहे को भूल जाइए और INSTRUMENT और इसे एक जटिल चौराहे से बदलें जिसमें teacher_id . शामिल हो , instrument_id और level_id . ये तीनों कॉलम इस चौराहे की तालिका की प्राथमिक कुंजी (यौगिक) होंगे। इस विकल्प में, आपके पास teacher_id . पर परिभाषित विदेशी कुंजी बाधाएं हैं और instrument_id (और level_id अगर यह वास्तव में LEVEL . के लिए एक विदेशी कुंजी है तालिका और न केवल एक पूर्णांक या स्ट्रिंग कोड)।

विकल्प दो है:TEACHER . के बीच सरल प्रतिच्छेदन रखें और INSTRUMENT (चलो इसे TEACHER_INSTRUMENT कहते हैं भले ही वह अकल्पनीय है) और एक उप-बाल तालिका जोड़ें जो उन स्तरों को परिभाषित करती है जिन्हें पढ़ाया जा सकता है। यह सब-चाइल्ड टेबल (इसे SKILL कहते हैं) ) में एक level_id है और TEACHER_INSTRUMENT . के लिए एक विदेशी कुंजी . अगर TEACHER_INSTRUMENT . की प्राथमिक कुंजी teacher_id . का संयोजन है और instrument_id फिर SKILL तालिका में विकल्प एक के समान तीन कॉलम होने जा रहे हैं। यह विकल्प क्या अलग बनाता है? विदेशी कुंजी बाधा SKILL चौराहे की मेज पर होना चाहिए, न कि TEACHER और INSTRUMENT ।

यह महत्वपूर्ण क्यों है? यदि आप विकल्प एक चुनते हैं, तो आपको कौशल की पूरी तरह से आबादी वाला ग्रिड प्राप्त करने के लिए कुछ अतिरिक्त क्वेरी तर्क की आवश्यकता हो सकती है, क्योंकि कोई संदर्भात्मक अखंडता बाधा नहीं है जिसे आप परिभाषित कर सकते हैं कि यह सुनिश्चित करेगा कि प्रत्येक शिक्षक/उपकरण संयोजन के लिए सभी कौशल स्तर पॉप्युलेट हो जाएं।

दूसरी ओर, यदि आप विकल्प दो को चुनते हैं, तो आपको उन चिंताओं को अलग करने का लाभ होता है जो इसका उपयोग कर सकते हैं और वे इसे कितनी अच्छी तरह सिखा सकते हैं।

आप जिस चीज से बचना चाहते हैं, वह एक टेबल है जिसमें सिर्फ शिक्षक/साधन संबंध होता है और फिर दूसरा जो (स्वतंत्र रूप से) उस रिश्ते को दोहराता है लेकिन कौशल स्तर का विवरण जोड़ता है। अगर आप ऐसा करते हैं, तो आप इन दो चीजों के सिंक से बाहर होने का जोखिम उठाते हैं।