2008-10-20 24 views
12

ऑब्जेक्ट-रिलेशनल मैपिंग पर अच्छी तरह से चर्चा की गई है, यहां पर भी शामिल है। मुझे कुछ दृष्टिकोण और नुकसान और समझौता के साथ अनुभव है। सही संकल्प ऐसा लगता है कि इसे ओओ या रिलेशनल मॉडल में बदलाव की आवश्यकता है।रिलेशनशिप मैपिंग के लिए कार्यात्मक उद्देश्य से ऑब्जेक्ट से आसान है?

यदि कोई कार्यात्मक भाषा का उपयोग करना है, तो क्या वही समस्या स्वयं उपस्थित होती है? ऐसा लगता है कि इन दो प्रतिमानों को ओओ और आरडीबीएमएस से बेहतर तरीके से फिट होना चाहिए। आरडीबीएमएस में सेट में सोचने का विचार स्वचालित समांतरता के साथ जाल लगता है कि कार्यात्मक दृष्टिकोण वादा करने लगते हैं।

क्या किसी के पास कोई दिलचस्प राय या अंतर्दृष्टि है? उद्योग में खेलने की स्थिति क्या है?

+0

वास्तव में, क्या यह वास्तव में समझ में आता है? कार्यात्मक प्रोग्रामिंग डेटा मॉडलिंग का कोई मानक तरीका प्रदान नहीं करता है जिसे कुछ हद तक संबंधपरक या ओओ डेटा मॉडलिंग से तुलना की जा सकती है। तो आईएमएचओ "मैपिंग" मांगना एक सार्थक सवाल नहीं है। कोई पूछ सकता है कि क्या आरडीबीएमएस को कार्यात्मक अवधारणाओं को जोड़ना समझ में आता है, वास्तव में एसक्यूएल पहले से ही कुछ कार्यात्मक अवधारणाओं में है। –

उत्तर

5

संबंधपरक डेटाबेस को विस्तारित करने की कठोर समस्याएं विस्तारित लेनदेन, डेटा-प्रकार के विसंगतियां, स्वचालित क्वेरी अनुवाद और N+1 Select जैसी चीजें हैं जो संबंधपरक प्रणाली को छोड़ने की मौलिक समस्याएं हैं - - मेरी राय में - बदलकर बदलना नहीं प्राप्त प्रोग्रामिंग प्रतिमान।

2

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

मुख्य समस्या जो मैं देखता हूं वह प्रदर्शन है। आज आरडीएमएस को कार्यात्मक प्रश्नों के साथ प्रयोग करने के लिए डिज़ाइन नहीं किया गया है, और शायद कुछ मामलों में खराब व्यवहार करेगा।

2

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

लेकिन पढ़ने के लिए, कार्यात्मक भाषा (के रूप में यह डीबी की परवाह किए बिना हो रहा है) कुछ समस्या डोमेन के साथ और अधिक प्राकृतिक हो सकता है

कार्यात्मक < -> आरडीबीएमएस मानचित्रण OO < करने के लिए कोई बड़ा मतभेद होना चाहिए - > आरडीएमबीएस मैपिंग्स। लेकिन मुझे लगता है कि यह इस बात पर निर्भर करता है कि आप किस प्रकार के डेटा प्रकार का उपयोग करना चाहते हैं, यदि आप एक ब्रांड नई डीबी स्कीमा के साथ एक प्रोग्राम विकसित करना चाहते हैं या विरासत डीबी स्कीमा, आदि के खिलाफ कुछ करना चाहते हैं ..

उदाहरण के लिए संघों के लिए आलसी fetches आदि शायद कुछ आलसी मूल्यांकन-संबंधित अवधारणाओं के साथ काफी अच्छी तरह से लागू किया जा सकता है। (भले ही उन्हें ओओ के साथ काफी अच्छी तरह से किया जा सकता है)

संपादित करें: कुछ googling के साथ मुझे HaskellDB (Haskell के लिए एसक्यूएल लाइब्रेरी) मिला - यह कोशिश करने लायक हो सकता है?

2

मैंने कार्यात्मक-संबंधपरक मैपिंग, प्रति से नहीं किया है, लेकिन मैंने आरडीबीएमएस तक पहुंच बढ़ाने के लिए कार्यात्मक प्रोग्रामिंग तकनीकों का उपयोग किया है।

डेटासेट से शुरू करना काफी आम है, उस पर कुछ जटिल गणना करें, और परिणामों को संग्रहित करें, जहां परिणाम अतिरिक्त मूल्यों के साथ मूल का सबसेट हैं, उदाहरण के लिए। अनिवार्य दृष्टिकोण यह निर्देश देता है कि आप अपने प्रारंभिक डेटासेट को अतिरिक्त नल कॉलम के साथ स्टोर करते हैं, अपनी गणना करें, फिर गणना किए गए मानों के साथ रिकॉर्ड अपडेट करें।

उचित लगता है। लेकिन इसके साथ समस्या यह बहुत धीमी हो सकती है।यदि आपके गणना के लिए अद्यतन क्वेरी के अलावा किसी अन्य SQL कथन की आवश्यकता है, या यहां तक ​​कि एप्लिकेशन कोड में भी करने की आवश्यकता है, तो आपको सचमुच उन रिकॉर्ड्स की खोज करनी होगी जिन्हें आप अपने परिणामों को सही पंक्तियों में संग्रहीत करने के लिए गणना के बाद बदल रहे हैं ।

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

मैं (ab) एक आरडीबीएमएस इस तरह से इस्तेमाल किया और SQL कथन है कि ज्यादातर इस तरह देखा लेखन समाप्त हो गया ...

create table temp_foo_1 as select ...; 
create table temp_foo_2 as select ...; 
... 
create table foo_results as 
    select * from temp_foo_n inner join temp_foo_1 ... inner join temp_foo_2 ...; 

क्या यह अनिवार्य रूप से कर रही है अपरिवर्तनीय बाइंडिंग का एक समूह पैदा कर रही है। अच्छी बात यह है कि, आप एक ही समय में पूरे सेट पर काम कर सकते हैं। आपको उन भाषाओं की याद दिलाता है जो आपको Matlab की तरह matrices के साथ काम करने देते हैं।

मुझे लगता है कि यह समांतरता को और भी आसान बनाने की अनुमति देगा।

एक अतिरिक्त पर्क यह है कि इस तरह से बनाए गए तालिकाओं के लिए कॉलम के प्रकार निर्दिष्ट नहीं किए जाते हैं क्योंकि वे उन स्तंभों से अनुमानित हैं जिन्हें वे चुना गया है।

+2

यह दुरुपयोग नहीं है, यह SQL का उपयोग करने का सही तरीका है। आप एक सेट आधारित तरीके से काम करते हैं और यह सबसे अच्छा तरीका है। ओरेकल समानांतरता वाले एसक्यूएल कथन को निष्पादित कर सकता है, मुझे लगता है कि अन्य डीबी भी ऐसा कर सकते हैं। – tuinstoel

1

कि अपनी आवश्यकताओं पर निर्भर करता है

  1. यदि आप डेटा संरचनाओं पर ध्यान केंद्रित जेपीए/हाइबरनेट
  2. की तरह एक ORM का उपयोग आप उपचार पर प्रकाश डाला चाहते हैं, FRM पर एक नज़र लेने के लिए चाहते हैं पुस्तकालयों: QueryDSL या Jooq
  3. आप धुन पर विशिष्ट डेटाबेस के लिए अपने एसक्यूएल अनुरोध की जरूरत है, JDBC और देशी एसक्यूएल का अनुरोध करता है

विभिन्न "रिलेशनल मानचित्रण" प्रौद्योगिकियों के strengh पोर्टेबिलिटी है का उपयोग करें: आप सुनिश्चित करते हैं कि आपका एप्लिकेशन अधिकांश एसीआईडी ​​डेटाबेस पर चलाएगा। अन्यथा, जब आप मैन्युअल रूप से SQL अनुरोध लिखते हैं तो आप विभिन्न SQL बोलियों के बीच मतभेदों का सामना करेंगे।

बेशक

आप SQL92 मानक के लिए खुद को नियंत्रित कर सकते हैं (और फिर कुछ कार्यात्मक प्रोग्रामिंग करते हैं) या आप functionnal प्रोग्रामिंग की कुछ अवधारणाओं का पुन: उपयोग कर सकते हैं ORM चौखटे के साथ

ORM strenghs एक सत्र वस्तु जो कार्य कर सकते हैं भर में निर्माण कर रहे हैं एक बाधा के रूप में:

  1. यह अंतर्निहित डेटाबेस लेनदेन चलने तक वस्तुओं के जीवन चक्र का प्रबंधन करता है।
  2. यह आपके जावा ऑब्जेक्ट्स और आपकी डेटाबेस पंक्तियों के बीच एक-से-एक मैपिंग बनाए रखता है (और डुप्लिकेट ऑब्जेक्ट्स से बचने के लिए आंतरिक कैश का उपयोग करें)।
  3. यह
  4. को हटाने के लिए स्वचालित रूप से एसोसिएशन अपडेट और अनाथ वस्तुओं का पता लगाता है, यह आशावादी या निराशावादी लॉक के साथ समवर्ती मुद्दों को संभालता है।

फिर भी, अपनी शक्तियों को भी अपनी कमजोरियों हैं:

  1. सत्र तो आप बराबर है/hashCode तरीकों लागू करने की जरूरत है वस्तुओं की तुलना करने के लिए सक्षम होना चाहिए। लेकिन ऑब्जेक्ट्स समानता को "व्यापार कुंजी" पर रूट किया जाना चाहिए और डेटाबेस आईडी नहीं (नई क्षणिक वस्तुओं में कोई डेटाबेस आईडी नहीं है!)। हालांकि, कुछ संशोधित अवधारणाओं में कोई व्यावसायिक समानता नहीं है (उदाहरण के लिए एक ऑपरेशन)। एक सामान्य वर्कअराउंड GUID पर निर्भर करता है जो डेटाबेस प्रशासकों को परेशान करता है।

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

  3. ओआरएम एपीआई कभी-कभी असली दुनिया के उपयोग के लिए अनुपयुक्त होते हैं। उदाहरण के लिए, वास्तविक विश्व वेब अनुप्रयोग डेटा प्राप्त करते समय कुछ "WHERE" खंड जोड़कर सत्र अलगाव को लागू करने का प्रयास करते हैं ... फिर "सत्र.जेट (आईडी)" पर्याप्त नहीं है और आपको अधिक जटिल होने की आवश्यकता है डीएसएल (एचएसक्यूएल, मानदंड एपीआई) या मूल एसक्यूएल

  4. डेटाबेस ऑब्जेक्ट्स अन्य ढांचे (जैसे ओएक्सएम फ्रेमवर्क = ऑब्जेक्ट/एक्सएमएल मैपिंग) को समर्पित अन्य ऑब्जेक्ट्स के साथ संघर्ष करता है। उदाहरण के लिए, यदि आपकी आरईएसटी सेवाएं किसी व्यावसायिक ऑब्जेक्ट को क्रमबद्ध करने के लिए जैक्सन लाइब्रेरी का उपयोग करती हैं। लेकिन यह जैक्सन वास्तव में एक हाइबरनेट वन के लिए मानचित्र है। तो या तो आप दोनों को मर्ज करने और अपने एपीआई और अपने डेटाबेस के बीच एक मजबूत युग्मन प्रकट होता है या फिर आप एक अनुवाद को लागू करना चाहिए और सभी कोड आप ORM से बचाया वहाँ खो दिया है ...

दूसरी ओर , एफआरएम "ऑब्जेक्ट रिलेशनल मैपिंग" (ओआरएम) और देशी एसक्यूएल प्रश्नों (जेडीबीसी के साथ)

एफआरएम और ओआरएम के बीच मतभेदों को समझाने का सबसे अच्छा तरीका एक डीडीडी दृष्टिकोण को अपनाने में शामिल है।

  • वस्तु संबंधपरक मानचित्रण "रिच डोमेन ऑब्जेक्ट" जो जावा वर्गों जिसका राज्यों डेटाबेस लेनदेन
  • कार्यात्मक संबंधपरक मानचित्रण "गरीब डोमेन वस्तुओं" जो अपरिवर्तनीय हैं पर इतना निर्भर करता है (के दौरान परिवर्तनशील हैं के उपयोग की शक्ति प्रदान आप एक नया हर बार जब आप अपनी सामग्री) को बदलने के लिए

यह कमी ORM सत्र पर डाल दिया जाता है और यह एसक्यूएल पर एक डीएसएल पर समय के सबसे अधिक निर्भर करता है चाहता हूँ क्लोन करने के लिए होती है (इसलिए पोर्टेबिलिटी कोई फर्क नहीं पड़ता) लेकिन दूसरी ओर, आपको लेन-देन के विवरणों को देखना होगा, concurrenc वाई मुद्दे

List<Person> persons = queryFactory.selectFrom(person) 
    .where(
    person.firstName.eq("John"), 
    person.lastName.eq("Doe")) 
    .fetch();