हाइबरनेट - एक-से-एक का प्रतिनिधित्व करने के लिए कई से एक का उपयोग क्यों करें?

Question

मैंने देखा है कि लोग एक-से-एक संबंधों का प्रतिनिधित्व करने के लिए कई से एक मैपिंग का उपयोग करते हैं। मैंने इसे गेविन किंग और लेखों पर एक पुस्तक में भी पढ़ा है।

<class name="Customer" table="CUSTOMERS"> 
    ... 
    <many-to-one name="shippingAddress" 
       class="Address" 
       column="SHIPPING_ADDRESS_ID" 
       cascade="save-update" 
       unique="true"/> 
    ... 
</class> 

के रूप में (यह हवाले से) पुस्तक कारण हैं:

उदाहरण के लिए, एक ग्राहक ठीक एक शिपिंग पता नहीं है सकते हैं, और एक शिपिंग पता केवल एक ही ग्राहक से संबंध रखते हैं कर सकते हैं, मानचित्रण के रूप में दिया जाता है:

"तुम परवाह नहीं है क्या संघ का लक्ष्य पक्ष में है, ताकि आप इसे कई हिस्सा बिना एक टू-वन संघ की तरह व्यवहार कर सकते हैं।"

मेरा प्रश्न है, many-to-one का उपयोग क्यों करें और one-to-one नहीं? one-to-one के बारे में यह क्या है जो इसे many-to-one पर कम वांछनीय विकल्प बनाता है?

धन्यवाद।

Answer 1

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

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

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

दूसरे शब्दों में, एक many-to-one का उपयोग कर रास्ता एक-से-एक विदेशी कुंजी संघों (जो वास्तव में हो सकता है की तुलना में साझा प्राथमिक कुंजी एक-से-एक संघों अधिक लगातार कर रहे हैं) को मैप करने के लिए है।

Answer 2

यह आधिकारिक हाइबरनेट दस्तावेज़ों में भी है: http://docs.jboss.org/hibernate/core/3.3/reference/en/html/associations.html#assoc-bidirectional-121।

यह पूरी तरह से अनुचित नहीं है। कई से एक अंत कहता है: मैं अपने कॉलम में से किसी एक के अंत में एक आईडी के माध्यम से मैप किया गया हूं। आप कई-एक-एक के लिए सटीक उसी डेटाबेस स्कीमा का उपयोग करेंगे।

Answer 3

मैं कहूंगा कि यह समस्या मूल रूप से ऑब्जेक्ट-रिलेशनल प्रतिबाधा विसंगति से संबंधित है। किसी डेटाबेस में दो ऑब्जेक्ट प्रस्तुतियों को जोड़ने में सक्षम होने के लिए, आपको अपनी तालिकाओं के बीच कुछ प्रकार के रिश्ते की आवश्यकता होती है। हालांकि, डेटाबेस केवल 1: एन संबंध जानता है: अन्य सभी इसे से प्राप्त कर रहे हैं।

संबंधपरक डेटाबेस और ऑब्जेक्ट भाषाओं के साथ, यह उस अवधारणा के कम से कम अप्राकृतिक प्रतिनिधित्व को खोजने के लिए डेवलपर पर निर्भर करता है जिसे वह प्रस्तुत करना चाहता है (इस मामले में, 1: 1 संबंध)।

Answer 4

जैसा कि मैं समझता हूं कि हाइबरनेट को यह आवश्यक है कि दोनों ऑब्जेक्ट्स की प्राथमिक कुंजी 1 से 1 रिलेशनशिप में मेल खाती हो। बहुत से 1 उस आवश्यकता से बचाता है।

हालांकि कई से 1 जानकारी खो देता है कि कई तरफ केवल एक या शायद कोई वस्तु नहीं होनी चाहिए।

Answer 5

सबसे बड़ा अंतर है, साझा की गई कुंजी एक-से-एक मैपिंग 2 ऑब्जेक्ट्स एक-दूसरे से बंधे हैं, वे एक साथ मौजूद हैं।

f.e. यदि आप एक व्यक्ति और एक पता वर्ग है कि एक ही नाम के साथ तालिकाओं के लिए बाध्य कर रहे हैं बनाने के लिए, प्रत्येक व्यक्ति के ठीक एक पता होगा ...

वर्ग व्यक्ति, गुण: पता तालिका व्यक्ति, कॉलम: आईडी, नाम तालिका पता, कॉलम: आईडी, शहर

कई-एक संबंध तालिका संरचना थोड़ा बदल जाता है, लेकिन एक ही प्रभाव प्राप्त किया जा सकता के साथ ...

• वर्ग व्यक्ति -> गुण: पता
• तालिका व्यक्ति -> कॉलम: आईडी, नाम, addressid (FK)
• तालिका पता -> कॉलम: आईडी, शहर

... लेकिन फिर भी अधिक। पता

तालिका व्यक्ति -> कॉलम: -> गुण

• वर्ग व्यक्ति: अब इस व्यक्ति के एक से अधिक पते हो सकता है आईडी, नाम, addressid (FK), shippingaddressid (FK)
• तालिका पता - > कॉलम: आईडी, शहर

दो विदेशी कुंजी (addressid और shippingaddressid) एक एकल डीबी प्रविष्टि को इंगित कर सकता है ... या एक ही पते के 2-3 व्यक्तियों के हैं सकता है। तो व्यक्ति की तरफ से कई लोगों के लिए यह पता है कि यह पता पक्ष से एक-एक है।

और अनुमान लगाएं कि केवल 1 आइटम के साथ एक-से-कई सहयोग क्या दिखता है? हाँ, बस एक-एक-एक की तरह ...

नोट: पता वास्तव में मूल्य वस्तु होना चाहिए, डीबी में साझा नहीं किया जाना चाहिए (इसलिए यह एक मूर्ख उदाहरण है, लेकिन मुझे लगता है कि यह ठीक रहेगा)

संक्षेप में तो:

1. में या मानचित्रण एक-से-एक के बाद एक यह
2. कई का उपयोग कर सीमाओं है है करने के लिए एक के लिए
3. एक को संभालने के लिए कठिन है बजाय मो है पुनः लचीला और एक ही चीज़