विदेशी कुंजी पर यूनिडायरेक्शनल एक से कई संगठनों से बचने की सिफारिश क्यों की जाती है?

Question

संभव डुप्लिकेट:
Hibernate unidirectional one to many association - why is a join table better?

हाइबरनेट ऑनलाइन प्रलेखन में, खंड 7.2.3 एक-से-कई के तहत, यह उल्लेख किया गया है, कि:

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

मुझे जानना है क्यों? मेरे दिमाग में आने वाली एकमात्र चीज है, यह कैस्केड डिलीट के दौरान समस्याएं पैदा कर सकती है। उदाहरण के लिए, व्यक्ति विदेशी कुंजी पर कई रिश्तों को संबोधित करता है, और पता व्यक्ति से पहले हटा दिया जाएगा।

क्या कोई सिफारिश के पीछे तर्कसंगत समझा सकता है?

एक विदेशी कुंजी पर एक यूनिडायरेक्शनल एक-से-कई संघ एक असामान्य है: मैं प्रति यहां चिपकाया वास्तविक सामग्री है 7.2.3. One-to-many

:

यहाँ संदर्भ दस्तावेज़ सामग्री के लिए लिंक है मामला, और अनुशंसित नहीं है।

<class name="Person"> 
    <id name="id" column="personId"> 
     <generator class="native"/> 
    </id> 
    <set name="addresses"> 
     <key column="personId" 
      not-null="true"/> 
     <one-to-many class="Address"/> 
    </set> 
</class> 

<class name="Address"> 
    <id name="id" column="addressId"> 
     <generator class="native"/> 
    </id> 
</class> 

---

create table Person (personId bigint not null primary key) 
create table Address (addressId bigint not null primary key, personId bigint not null) 

आप के बजाय संघ के इस प्रकार के लिए एक मेज में शामिल होने का उपयोग करना चाहिए।

Answer 1

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

इस के लिए दो पहलू हैं:

• यूनिडायरेक्शनल
• एक-से-कई

thread@CalmStorm के पतों पर नष्ट कर दिया जवाब लिंक केवल दूसरे इन चीजों में से, लेकिन चलो इसके साथ शुरू करते हैं।

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

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

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

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

इसमें कुछ कामकाज हैं। एक birectional एक से कई संगठनों का उपयोग करना है। in the document you cite के मुताबिक यह सबसे आम दृष्टिकोण है। दूसरा दृष्टिकोण बाल वस्तु के मैपिंग को ट्विक करना है, लेकिन इसकी अपनी रैमिकेशंस है।