हाइबरनेट ट्यूटोरियल में, अध्याय 25 सर्वोत्तम प्रथाओं का कहना है कि हमें एक इंटरमीडिएट लिंक क्लास के साथ कई से कई लोगों के बजाय 2 एक से अधिक रिश्तों का उपयोग करना चाहिए। मैं नहीं देख सकता कि इसका क्या फायदा है: 3 डी इकाई बनाने के लिए बेहतर क्यों है, जबकि कई लोग इस इंटरमीडिएट लिंक के रूप में कार्यरत एक तालिका में उत्पन्न हो सकते हैं। हालांकि यह सिफारिश एक अच्छे कारण के लिए होनी चाहिए।2 कई से कई
क्या कोई इस सिफारिश के लिए जमीन समझा सकता है? धन्यवाद।
कई से अधिक रिश्ते अक्सर संबंधों में भाग लेने वालों के बजाय संबंधों से जुड़े संबंधों से जुड़े अतिरिक्त डेटा को जन्म देते हैं — रिश्ते में प्रतिभागियों के बजाय, मेरे अनुभव में, यह अपवाद के बजाय मानक है)। उदाहरण के लिए सदस्यों और समूहों को कई से कई तरीकों से जोड़ा जा सकता है, और आप जानना चाहते हैं कि कोई सदस्य समूह में कब शामिल होता है, उनकी सदस्यता स्थिति क्या होती है (नया, लंबित, निलंबित, ...) और इसी तरह।
यदि आप रिश्तों को सीधे कई लोगों के रूप में मॉडलिंग करके शुरू करते हैं और तदनुसार अपना पूरा कोड लिखते हैं, तो जुड़ने वाली तालिका को हिट करने वाला पहला अतिरिक्त कॉलम आपके मॉडल और कोड का एक गुच्छा तोड़ देगा।
+1 (और मुझे लगता है कि कई से अधिक टेबल का उपयोग न करने के लिए प्रदर्शन कारण भी हैं: हाइबरनेट में जॉइन टेबल अपडेट करते समय इष्टतम होने में कठिनाई होगी।) – Thierry
@ थिएरी, आप "कई से बच नहीं सकते कई से अधिक रिश्तों को मॉडलिंग करते समय - कई "टेबल (मैं इसे शामिल तालिका में कॉल करना पसंद करता हूं)। मैं जो कह रहा हूं वह यह नहीं है कि आपके पास जॉइन टेबल नहीं होनी चाहिए, लेकिन संबंधित ऑब्जेक्ट्स पर संग्रह गुणों के माध्यम से इसे लागू करने के बजाय आपको सीधे ओआरएम में जॉइन टेबल को मॉडल करना चाहिए। –
हां, मैं पूरी तरह से आपसे सहमत हूं, और मैंने जो लिखा है उसमें एक टाइपो है: मैं कहना चाहता था कि कई से कई एक से अधिक कुशल हो सकते हैं (इसलिए 'उपयोग न करने के बजाय' 'उपयोग के लिए' लिखना चाहता था, जो काफी विपरीत अर्थ है-_-)। तो जब भी आप जानते हों कि आपके पास जॉइन टेबल में कोई अन्य संपत्ति नहीं है, तो यह एक अच्छा विचार हो सकता है कि इसे एक इकाई के रूप में मैपिंग पर विचार करें। – Thierry