जब आप डेटाबेस परिप्रेक्ष्य से अनुप्रयोग के पास आ रहे हैं जैसे Doctrine2 (PHP) या Hibernate (Java) जिसमें से "व्युत्पन्न" है, उचित नहीं है। जब आप दूसरी तरफ जाना चाहते हैं तो ये अधिक उपयुक्त होते हैं (यानी "मेरे पास ओओ डोमेन मॉडल है और इसे एक रिलेशनल डीबी में जारी रखने की आवश्यकता है" नहीं, "मेरे पास एक रिलेशनल डीबी है और एक (जेनरेट?) ओओ इंटरफेस चाहिए इसके लिए, डेटाबेस पक्ष पर जो कुछ भी समझौता किए बिना ")। यदि आप दृष्टिकोण में इस महत्वपूर्ण अंतर के बावजूद उनका उपयोग करते हैं और आप अपने ऑब्जेक्ट मॉडल से अधिक अपने रिलेशनल स्कीमा से प्यार करते हैं तो आप निराश हो जाएंगे।
ओआरएम उपकरण की विभिन्न श्रेणियों के बीच अंतर करना वास्तव में महत्वपूर्ण है क्योंकि वे विभिन्न विकास मॉडल पर ध्यान केंद्रित करते हैं।
शायद प्रोपेल या रेडबीनपीएचपी को आज़माएं, जो किसी डेटाबेस-संचालित विकास मॉडल के लिए उपयुक्त प्रतीत होता है, जिसमें लगभग कोई मैपिंग नहीं चलती है, केवल सादा जेनरेट (और आमतौर पर गूंगा) "डेटा ऑब्जेक्ट्स" और अधिक अमूर्त नहीं होता है। विदेशी कुंजी फ़ील्ड केवल इन समाधानों में सीधे वस्तुओं में डाल दिए जाते हैं, इसलिए वे आपके द्वारा इच्छित सभी समग्र सामग्री का "समर्थन" कर सकते हैं।
सिद्धांत कुंजी या हाइबरनेट जैसे समाधान समग्र कुंजी के उपयोग को हतोत्साहित करते हैं और इसलिए केवल उन्हें एक निश्चित स्तर तक समर्थन देते हैं (हाइबरनेट बहुत दूर जाता है लेकिन फिर भी उन्हें उपयोग करने की अनुशंसा नहीं की जाती है)।
व्यक्तिगत रूप से मैं समग्र कुंजी का प्रशंसक नहीं हूं (बिना किसी अतिरिक्त डेटा वाले कई से अधिक लिंक टेबल के अपवाद के साथ) क्योंकि मैं एप्लिकेशन/डोमेन-मॉडल/ऑब्जेक्ट साइड से चीजों से ज्यादा कुछ करता हूं और वस्तुओं के लिए मैप किए गए समग्र कुंजी अक्सर काम करने के लिए दर्द होते हैं, भले ही अंतर्निहित मैपिंग तकनीक उनका समर्थन करे। सरोगेट कुंजी (या कम से कम एकल-क्षेत्र प्राकृतिक कुंजी) चीजों को अधिक सरल बनाती है। मैं एक रिलेशनल-डेटाबेस-सामान्यीकरण-fetishist नहीं हूं और "बेहतर प्रदर्शन" मेरे दृष्टिकोण से अत्यधिक संदिग्ध है। कभी-कभी जुड़ने से बचने से आपको बचाया नहीं जा सकता है यदि आपके पास सिस्टम में वास्तविक प्रदर्शन समस्याएं हैं।
नहीं, आपकी जानकारी बेकार है। यहां तक कि सिद्धांत 1 समग्र प्राथमिक कुंजी का समर्थन करता है। मुझे समग्र प्राथमिक कुंजी और समग्र विदेशी कुंजी के आधार पर बहु-स्तंभ संबंधों की आवश्यकता है। सिद्धांत 2 संदर्भ कहता है कि यह यहां इसका समर्थन नहीं करता है: http://www.doctrine-project.org/projects/orm/2.0/docs/reference/limitations-and-known-issues/en#limitations-and-known -issues – Daimon
हाँ, क्षमा करें, आप सही हैं, मैंने इसे देखा है। मैं v1.2 – trix
के साथ काम कर रहा था मैं अब भी डॉक्टरेट v1.2 का उपयोग कर रहा हूं। ऐसे मामलों में मैं बदसूरत सरोगेट-चाबियाँ बनाता हूं जो आवश्यक सुविधा का अनुकरण करते हैं ... लेकिन यह अच्छे संबंधपरक डेटा डिज़ाइन को खराब करता है और कम प्रदर्शन (अनावश्यक सूचकांक) में समाप्त होता है – Daimon