क्या ओ/आर मैपिंग इसके लायक है?

Question

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

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

प्रश्न: क्या आपको अपने संगठन में राउंड-ट्रिप समस्या से निपटने का कोई तरीका मिला है? क्या कोई एसक्यूएल-मार्शलिंग फ्रेमवर्क है जो अच्छी तरह से स्केल करता है, और आसानी से बनाए रखता है?

(हाँ, मुझे पता है कि शुद्ध एसक्यूएल मुझे डाटाबेस विक्रेता के लिए बाध्य हो सकता है। लेकिन यह संभव मानकों का अनुपालन करने एसक्यूएल लिखने के लिए है।)

Answer 1

मुझे लगता है कि आप जो चाहते हैं वह एक ऐसा समाधान है जो आपको अन्य साधनों का उपयोग किए बिना ओआरएम के लाभ को अधिकतम करता है। हमारे पास हमारे आवेदन में उतनी ही समस्या है; बहुत भारी सवाल, और एक बड़ा डेटा मॉडल। डेटा मॉडल के आकार को देखते हुए, ओआरएम आवेदन के विशाल बहुमत के लिए अमूल्य है। यह हमें एसक्यूएल स्क्रिप्ट को हाथ से बनाए रखने के प्रयासों के बिना डेटा मॉडल का विस्तार करने की अनुमति देता है। इसके अलावा, और आपने इस पर स्पर्श किया, हम चार डेटाबेस विक्रेताओं का समर्थन करते हैं, इसलिए अमूर्त अच्छा है।

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

तो, संक्षेप में (हाँ, छोटा) हाँ, ओआरएम इसके लायक है, लेकिन किसी समस्या के हर समाधान की तरह, यह एक पैनसिया नहीं है।

Answer 2

सामान्य तौर पर, ORMs डेवलपर उत्पादकता एक बहुत तो मैं वृद्धि डी उनका उपयोग तब तक करते हैं जब तक वे मूल्यवान होने की तुलना में एक बड़ी समस्या बन जाते हैं। यदि आपकी अधिकांश तालिकाएं इतनी बड़ी हैं कि आपको बहुत सारी समस्याएं आ रही हैं, तो ओआरएम को मिटाने पर विचार करें। मैं निश्चित रूप से यह नहीं कहूंगा कि ओआरएम सामान्य रूप से एक बुरा विचार है। अधिकांश डेटाबेस काफी छोटे होते हैं और अधिकांश प्रश्न काफी सरल होते हैं कि वे अच्छी तरह से काम करते हैं।

मैंने खराब प्रदर्शन करने वाले प्रश्नों के लिए संग्रहित प्रक्रियाओं या हाथ से लिखित एसक्यूएल का उपयोग कर उस समस्या को दूर कर लिया है। डीबीए संग्रहित प्रक्रियाओं से प्यार करते हैं क्योंकि वे आपको बताए बिना उन्हें संशोधित कर सकते हैं। अधिकांश (यदि नहीं सभी) ओआरएम आपको हाथ से लिखित एसक्यूएल या संग्रहीत प्रक्रियाओं में मिश्रण करने की अनुमति देता है।

Answer 3

आज के ओ/आर ढांचे, जैसा कि मुझे विश्वास है कि आप परिचित हैं, मैन्युअल रूप से कुछ प्रश्नों को परिभाषित करने के विकल्प का समर्थन करते हैं ((एन) हाइबरनेट करता है)। जिसका उपयोग स्कीमा के जटिल भागों के लिए किया जा सकता है, और सीधे-आगे के हिस्सों के लिए ढांचे द्वारा प्रदत्त ओआरएम का उपयोग किया जाता है।

आपके लिए जांच करने के लिए एक और चीज iBatis ढांचे (http://ibatis.apache.org/) हो सकती है। मैंने इसका उपयोग नहीं किया है, लेकिन मैंने पढ़ा है कि यह एसक्यूएल के करीब है और डेटाबेस से परिचित लोगों और एसक्यूएल इसे हाइबरनेट जैसे पूर्ण उड़ाए गए ओआरएम ढांचे पर पसंद करते हैं, क्योंकि यह ओआरएम की पूरी तरह से अलग अवधारणा की तुलना में उनके करीब है।