ORM द्वारा डेटाबेस अमूर्त उपयोग करने के क्या लाभ हैं? [बन्द है]

Question

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

ORM का विचार यह है कि यह सब कुछ डेटाबेस को अज्ञेय बनाकर मेरी मदद करने की कोशिश कर रहा है। यह बहुत अच्छा लगता है, लेकिन अक्सर एक कारण है कि मैं एक विशिष्ट डेटाबेस सिस्टम क्यों चुनता हूं। लेकिन डेटाबेस अज्ञेय मार्ग पर जाकर, ORM सबसे कम सामान्य भाजक लेता है, जिसका अर्थ है कि मैं सबसे छोटे सेट के साथ समाप्त होता है (सभी डेटाबेस द्वारा समर्थित वाले)।

क्या होगा अगर मुझे पता है कि लंबे समय तक मैं अंतर्निहित डेटाबेस को स्विच नहीं करूंगा? डेटाबेस-विशिष्ट सुविधाओं तक पहुंच क्यों नहीं?

Comments

+1: बहुत दिलचस्प है। मैं आमतौर पर ओआरएम का एक प्रस्तावक रहा हूं, लेकिन मैंने आमतौर पर आरडीबीएमएस को समान माना है (जो मैंने हाल ही में गलत देखना शुरू किया है)।

— स्टीवन एवर्स

ऐसा लगता है कि आप सिर्फ अपनी राय की पुष्टि चाहते हैं; एक ब्लॉग आपको क्यू एंड ए साइट से बेहतर सूट कर सकता है।

संभवतः आपको ORM द्वारा प्रदान की जाने वाली चीज़ों से अधिक की आवश्यकता नहीं है। आप बस अपने ऑब्जेक्ट डेटा को डेटाबेस में स्टोर करना चाहते हैं और यही ओआरएम करेगा। आपको किसी अन्य 'सुविधाएँ' की आवश्यकता नहीं होनी चाहिए।

— CJ7

Answer 1

मैं इसे उसी तरह देखता हूं। कोई भी अमूर्तता, जो आवश्यक होने पर आपको इसे कम करने की अनुमति नहीं देती है, क्योंकि यह आपके कोड में सभी प्रकार के बदसूरत अमूर्त आक्रमणों की ओर जाता है।

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

IMO किसी भी ORM के पास यह सुविधा नहीं है वह उस बिट के लायक नहीं है जिसे वह संकलित करता है।

Comments

drops it directly into the query it's generatingदिलचस्प लगता है। क्या आप जानते हैं कि इस होमग्राउंड ORM को लिखने में आपको कितना समय लगा? मैं खुले स्रोत ओआरएम में से एक में इस तरह से कुछ देखना चाहता हूं।

— 3

+1। मेरे एप्लिकेशन (डेटा) के सबसे महत्वपूर्ण पहलू के साथ काम करना आखिरी चीज है जिसे मैं अमूर्त करना चाहता हूं और कनेक्शन खो देता हूं।

— फॉस्को

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

— फ्रैंक शीयर सेप

@Jblue: कोई विचार नहीं। यह सब वर्षों पहले लिखा गया था, इससे पहले कि मैं काम पर रखा गया। वे किसी भी शब्द का उपयोग करने से पहले एक ORM सेट करते थे। यह आमतौर पर हमारे कोडबेस में "ऑब्जेक्ट मॉडल" कहा जाता है।

— मेसन व्हीलर

मैं सहमत हूँ। बुनियादी और सामान्य सामान के लिए ORM बहुत मददगार हैं। लेकिन कभी-कभी आपको थोड़ी गहराई में जाने की आवश्यकता होती है, और यदि ओआरएम वह क्षमता नहीं देता है, तो यह आपके लिए समस्याओं का एक और स्रोत है।

— निकोस स्टेयकाकिस

Answer 2

ORM सबसे कम सामान्य भाजक लेता है

मुझे आपके कथन से असहमत होना चाहिए। मैं nHibernate को एक उदाहरण के रूप में लूंगा । यह फ्रेमवर्क बहुत सारे डेटाबेस का समर्थन करता है, जिसमें सबसे लोकप्रिय वाले भी शामिल हैं, चाहे संस्करण (और समर्थित सुविधाएँ), ज्यादातर ORM की तरह।

त्वरित नोट: आप केवल डेटाबेस अमूर्त का उल्लेख करते हैं। यह कई लाभों में से एक है, लेकिन मुझे वास्तव में लगता है कि वस्तु उन्मुख विशेषताएं अधिक शक्तिशाली हैं (जैसे: विरासत)। और You design your domain model first...

... अमूर्त वापस। यह सबसे कम आम भाजक नहीं है। में nHibernate , आप बोलियां हैं। यह आपको विभिन्न डेटाबेस को क्वेरी करने के लिए एक ही कोड का उपयोग करने की अनुमति देता है। बोलियां आपके लिए सुविधा प्रबंधन का ध्यान रखती हैं। सही कथन है कि है a given dialect will try to use all the power of a given database system।

एक उदाहरण के रूप में SqlServer2005जब बोली लगाई गई थी कि नए SQL Server 2005 पेजिंग सुविधाओं का लाभ ले रही थी। उस बोली का उपयोग करने के बजाय SqlServer2000सिर्फ अपने प्रदर्शन को बढ़ाया।

बेशक कुछ अपवाद हैं, लेकिन एनहाइबनेट के साथ काम करने के कई वर्षों में मेरा एक भी सामना नहीं हुआ, और मेरे आवेदन बहुत डेटा केंद्रित हैं।

Comments

NHibernate की वकालत करने के लिए +1। अन्य ORM की तुलना में एक सीखने की अवस्था का बिट, लेकिन प्रयास इसके लायक है।

— richeym

मैं इस पर कुछ डीबीए से सुनना चाहूंगा। मेरी आखिरी नौकरी में, हाइबरनेट कुछ भी नहीं था, लेकिन परेशानी (यह उत्पन्न SQL बिल्कुल घृणित था।)

— Fosco

इस टिप्पणी के लिए +1। यह हाजिर है। जब आप एक अच्छे ORM की शक्ति की तुलना करना शुरू करते हैं जैसे nHibernate (कैशिंग, आलसी-लोडिंग, आदि के साथ) तो आप देखते हैं कि यह अमूर्त क्यों अच्छा है और आपके डेटाबेस-विशिष्ट की आवश्यकताएं कम महत्वपूर्ण क्यों हैं।

— क्रिस होम्स

Fosco, nHibernate को एक और मौका दें। किसी भी अन्य टेक्नोलॉय की तरह, आपको यह समझना होगा कि अंदर क्या चल रहा है, इसे ठीक से उपयोग करने के लिए।

+1, ORM एक विशेष चौराहा JDBC ड्राइवर के साथ जावा क्या कर सकता है, इसका एक अधिकतम प्रतिच्छेदन है। आप अपने आवेदन की दृढ़ता परत में निवेश की राशि का चयन करने के लिए स्वतंत्र हैं

— bobah

Answer 3

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

इसलिए, मुझे लगता है कि एक में कूदने से पहले प्रश्न होने चाहिए:

क्या आप वास्तव में उनका उपयोग करने से कुछ हासिल कर रहे हैं? यही है, क्या आप इसे उपयोग करने लायक बनाने के लिए, और अपने सिस्टम में एक अतिरिक्त जटिलता जोड़ने के लायक बनाने के लिए एक ORM टूल को लागू करके पर्याप्त मात्रा में प्रयास कर रहे हैं? (यह विशेष रूप से वाणिज्यिक ऐप्स के लिए सच है, जहां वह अतिरिक्त 'टुकड़ा' अब संभावित समर्थन समस्याओं के लिए एक अतिरिक्त वेक्टर है)

और फिर, क्या अतिरिक्त अमूर्त परत का ऐप पर नकारात्मक प्रभाव पड़ेगा? क्या यह हाथ से कोडित एसक्यूएल आदि की तुलना में धीमा होने वाला है।

Answer 4

ओ / आरएम की नियमित रूप से आलोचना की गई है। टेड न्यूर्ड ने कुछ साल पहले इसे " वियतनाम ऑफ़ कंप्यूटर साइंस " कहा था। हे / आरएम

अच्छी तरह से शुरू होता है, समय बीतने के साथ और अधिक जटिल हो जाता है, और लंबे समय से पहले अपने उपयोगकर्ताओं को एक प्रतिबद्धता में उलझा देता है जिसमें कोई स्पष्ट सीमांकन बिंदु नहीं है, कोई स्पष्ट जीत की स्थिति नहीं है, और कोई स्पष्ट निकास रणनीति नहीं है।

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

Comments

वहां खूब पढ़े। मैं करियर में फुल-सर्कल आया हूं और पूरी सफलता के साथ रिलेशनल मॉडल को दोबारा अपनाया है।

— जे क्यू कतार

+1 @Xepoch - मुझे हाल ही में चेहरे के बारे में फिर से पता चला है: ORMs - SQL को ठंड में क्यों छोड़ा जा रहा है? अमूर्त, निश्चित - लेकिन ORM SQL फ़ोबिया को बढ़ावा देने के लिए लगता है।

— सनवुकंग

@sunwukung, मैं हमेशा सहमत नहीं था, लेकिन मैं अब यह मानता हूं कि SQL को एक 1st-क्लास लॉजिक लेयर माना जाना चाहिए, न कि सिर्फ कुछ जिसे वायर प्रोटोकॉल के रूप में इस्तेमाल किया जाता है।

— जे क्यू कतार

Answer 5

विकल्प क्या है?

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

दिन के अंत में, आपको खुद से पूछना होगा - विकल्प क्या है?

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

Comments

मैं एक तर्कसंगत डेटाबेस का उपयोग करने की आवश्यकता पर सवाल उठाऊंगा। यह मुझे परेशान करता है कि लोग तुरंत RDBMSes पर कूद जाते हैं, भले ही वे सही समाधान न हों। उदाहरण के लिए, ऑब्जेक्ट डेटाबेस कई समस्याओं का एक बहुत ही सुंदर समाधान प्रदान करता है। क्या वे परिपूर्ण हैं? नहीं, लेकिन लोग उनका मूल्यांकन करने के लिए शायद ही कभी परेशान होते हैं। एक गड़बड़ी की प्रवृत्ति है, "मुझे डेटा संग्रहीत करने की आवश्यकता है, मैं एसक्यूएल का उपयोग करूंगा!"

— बजे मैट ओलेनिक

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

— डेविड थॉर्नले

Answer 6

एक ओआरएम मूल रूप से " अनस्टर्ड प्रोसीजर " होता है। वहां, मैंने एक शब्द गढ़ा।

सब कुछ एक ORM करता है, आप दृश्य, ट्रिगर और संग्रहीत प्रक्रियाओं के साथ दोहरा सकते हैं। वे कच्चे एसक्यूएल को दूर करने में मदद करते हैं और सामान्यीकृत डेटाबेस को सुसंगत रख सकते हैं। लेकिन यह केवल सरल मामलों के लिए अच्छी तरह से काम करता है। यदि प्रक्रिया करने के लिए बहुत अधिक माच डेटा हैं, तो वे प्रदर्शन नाली बन सकते हैं। (PHP में ORM अक्सर डेटा स्क्रिप्ट-साइड लेते हैं, क्योंकि SQL बिल्डर चेन सब कुछ अमूर्त नहीं कर सकते हैं।)

लेकिन हमेशा की तरह, यह सब हाथ में आवेदन और कार्य पर निर्भर करता है।

Comments

"अनस्टर्ड प्रोसीजर" - उचित शब्द है "Parameterized SQL"। आप केवल उस सतह को खरोंच रहे हैं जो आपके लिए एक परिपक्व ORM कर सकता है (बैचिंग, आलसी-लोडिंग आदि)

— richeym

@richeym: PHP में अधिकांश ORM तैयार किए गए कथनों का उपयोग नहीं करते हैं, और न ही मानकीकृत प्लेसहोल्डर। यह एसक्यूएल से बच रहा है और सभी तरह से सुगम है। यकीन है कि वे थकाऊ मैनुअल SQL प्रश्नों पर उच्च स्तरीय लाभ प्रदान करते हैं। क्रमिक रूप से हालांकि वे डेटाबेस से तर्क को संसाधित करते हैं, इसलिए "अनस्टर्ड प्रोसेस"।

— मारियो

Answer 7

एक बात जो ORM का उपयोग करने में दर्द करती है, वह यह है कि उनके कई प्रशंसक दावा करते हैं कि हमें अब SQL और RDB सिद्धांत जानने की आवश्यकता नहीं है। परिणाम अजीब से पूरी तरह से विपत्तिपूर्ण हैं। और यह लाख बार के बावजूद है कि ओआरएम 'पंडित और पंडित बताता है कि हमें ओआरएम को ठीक से उपयोग करने और कॉन्फ़िगर करने के लिए एसक्यूएल और आरडीबी सिद्धांत को अच्छी तरह से जानना चाहिए ।

क्यों लोग एक उपकरण लेते हैं, जिसके कई पर इसके उपयोग होते हैं, लेकिन सभी संदर्भ एक जादुई, सार्वभौमिक रूप से लागू चांदी की गोली में नहीं हैं।

Answer 8

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

ORM ( Propel , PHP में) के लिए धन्यवाद , हमने कोड के लिए कुछ तर्क विभाजित किए हैं, इसलिए एक फ़ंक्शन ने क्वेरी के "रिकॉर्ड मान्य" भाग को जोड़ा है, दूसरा सुरक्षा भाग ("ये रिकॉर्ड केवल तभी दिखाता है जब उपयोगकर्ता इन क्षमताओं "), ... यदि अंतर्निहित संरचना बदल गई (एक अतिरिक्त क्षेत्र जिसे" रिकॉर्ड वैधता "के लिए ध्यान में रखा जाना चाहिए), तो हमें केवल एक फ़ंक्शन को बदलना होगा, न कि बीस एसक्यूएल खंड।

हम एक ऐसी स्थिति से आए जहां सभी (अच्छी तरह से, सबसे) एसक्यूएल खंड एक अलग एक्सएमएल फ़ाइल में संग्रहीत किए गए थे, इसलिए "डेटाबेस परिवर्तन को संभालना आसान होगा"। मेरा विश्वास करो, वे नहीं थे। एक हिस्सा इतना भयानक था कि मुझे इसे डेली डब्ल्यूटीएफ को सौंपना पड़ा ।

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

Answer 9

लेकिन बिंदु यह है कि आप डेटाबेस से दूर प्रोग्राम करें, मतलब आपको यह सोचने की ज़रूरत नहीं है कि आप डेटाबेस में हैं।

मैं C # में काम करता हूं और LINQ का उपयोग करता हूं, इसलिए बहुत सारे और बहुत सारे धाराप्रवाह तरीके। मुझे यह सोचने की ज़रूरत नहीं है कि मेरी वस्तुओं को कैसे संग्रहीत या पाया जाता है, या यहां तक ​​कि कार्यक्रम के स्तर पर भी सहेजा जाता है, और व्यवसाय स्तर पर बहुत कम।

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

आप अभी भी फ़ंक्शंस DB-side लिख सकते हैं। अक्सर आप बस के माध्यम से उन्हें मैप कर सकते हैं।

और सबसे बढ़कर, इस तरह अलग होना परीक्षण क्षमता की अनुमति देता है और आपको (थोड़ा) बेहतर संरचित कोड लिखने के लिए मजबूर करता है

Comments

फिर, आपको डेटाबेस से दूर प्रोग्राम करने की आवश्यकता क्यों है? डेटाबेस को अपने विकास का एक अभिन्न हिस्सा क्यों न बनाएं क्योंकि आपने पहली जगह का उपयोग करने के लिए चुना है। अगर आपको RDBMS की आवश्यकता नहीं है तो ORM को क्यों बंद करना चाहिए?

— जेई कतार

यह एक अभिन्न अंग है। एक डेटाबेस संबंधों को बनाए रखने और लागू करने और कच्चे डेटा को पुनर्प्राप्त करने में बहुत अच्छी तरह से करता है। हालाँकि, इस डेटा के साथ आप जो चीजें करना चाहते हैं, वह सबसे पहले ओआरएम आवरण में संभाला जा सकता है। और महत्वपूर्ण बातों के अलावा, तर्क को व्यावसायिक परत से बाहर क्यों ले जाना है?

— बर्न_हैंड

@burnt_hand - "लेकिन बात यह है कि आप डेटाबेस से दूर कार्यक्रम करने के लिए है, जिसका अर्थ है कि आप डेटाबेस में आप की तरह सोचने की जरूरत नहीं है।" सार्वभौमिक लाभ क्या हैं? मैं इसे एक लाभ के रूप में देख सकता हूं जब आपका ऐप केवल वस्तुओं को बनाए रखने का एक रास्ता खोज रहा है। लेकिन रिलेशनल डेटा के लिए, ओएलटीपी और इस तरह, डेटाबेस से दूर प्रोग्रामिंग अपने आप को बड़ा समय खराब करने का एक तरीका है।

— luis.espinal

@ luis.espinal - क्या मतलब है अपने आप को बड़ा समय पेंच? मैं वास्तव में उत्सुक हूँ। आपके पास कोई उदाहरण है?

— बर्न_हैंड

@burnt_hand - वास्तव में मेरे पास कई वास्तविक उदाहरण हैं। सबसे हाल ही में एक बहुत बड़े डोमेन मॉडल शामिल हैं और प्रदर्शन के मामले के रूप में, परियोजना को स्टार्ट अप पर सभी हाइबरनेट मैपिंग अपलोड करना होगा। परिणामी सेशन फैक्ट्री 30% तक खाने वाली मेमोरी को समाप्त कर देती है ... सिर्फ बाइंडिंग के लिए। कोड बेस अब ORM के साथ भी प्रतिबद्ध है, और इसे फिर से लिखना असंभव है। यह अब वास्तविक निहितार्थ है क्योंकि एप्लिकेशन हार्डवेयर पर भौतिक सीमाओं के करीब पहुंच रहा है जिसे वह चलाना चाहता था। ओह।

— luis.espinal

Answer 10

ORMs कर सकते हैं आप डेटाबेस विशिष्ट के लिए पहुँच दे सुविधाओं के साथ ही, यह है जिस पर आप का उपयोग कर रहे ORM निर्भर करता है और क्या सुविधाओं यह प्रदान करता है।

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

मेरे लिए, ORM का उपयोग करने का मुख्य लाभ यह नहीं है कि यह एक एप्लिकेशन डेटाबेस अज्ञेय बनाता है (हालांकि यह एक अच्छी बात भी है), लेकिन यह कि मुझे सबसे अधिक भाग के लिए यह नहीं सोचना है कि चीजें कैसे संग्रहीत की जाती हैं और पुनः प्राप्त किया।

हालाँकि , कुछ बिंदु पर आपको अपने आवेदन की आवश्यकताओं के आधार पर किसी भी तरह इस बारे में सोचना होगा। ORM जादू नहीं है।

Answer 11

मैंने अपना खुद का लिखा जो मुझे चयन और आवेषण को आसान बनाने में मदद करता है।

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

मुझे लगता है कि मेरा आधा आधा उपयोगी है। मुझे ORM दुनिया में कुछ मदद मिलती है और क्वेरी वर्ल्ड में महत्वपूर्ण भाग करते हैं।

Answer 12

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

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

Comments

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

— luis.espinal

Answer 13

मेरा (सरल) दो सेंट:

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

2: ORMs का लाभ उस क्वेरी की जटिलता के लिए प्रत्यक्ष सहसंबंध में कम हो जाता है जिसे आपको चलाने की आवश्यकता है। जब आपके पास एक अच्छा सरल संबंध होता है - अर्थात उपयोगकर्ता -> पोस्ट, वे बहुत अच्छी तरह से काम कर सकते हैं। यह (IMO) यही कारण है कि अधिकांश ORMs / चौखटे इस तरह के उदाहरणों का उपयोग करते हैं। जब आपको जटिल प्रश्नों को चलाने की आवश्यकता होती है, हालांकि, आपके द्वारा उत्पन्न की जाने वाली ORMQL की मात्रा एक नियमित SQL क्वेरी की स्ट्रिंग लंबाई के बराबर होती है - लेकिन क्वेरी चालान को चलाने वाले ऑब्जेक्ट ग्राफ के कारण कम प्रदर्शन करने वाला, इस तरह की हार को इंगित करता है अमूर्त। तो, संक्षेप में - ORM आपके डेटाबेस कार्यों के पहले 30-50% के लिए शानदार हैं - लेकिन आखिरी के लिए भयानक। मुझे लगता है कि यह एक और कारण है कि एआर इतना प्रचलित है।

3: डेटाबेस से क्यों छिपाएं? क्या आप जावास्क्रिप्ट को सार करने के लिए एक सर्वर साइड भाषा का उपयोग करेंगे?

व्यक्तिगत रूप से मैं उन दृष्टिकोणों को मिलाता हूं:

• "उपयोगकर्ताओं" को लोड करने के लिए मूल बातें ORM का उपयोग करें
• कई पूर्व बेक्ड SQL प्रश्नों (जैसे selectLike, selectWhere) युक्त DAO का उपयोग करें।
• डीएओ का विस्तार करें जहां अधिक विशिष्ट लेकिन पुन: प्रयोज्य कस्टम प्रश्नों को जोड़ना आवश्यक है
• DAO के माध्यम से सरल डेटाबेस पहुँच प्रदान करें - यानी $ डेटा = Dao-> क्वेरी (आपकी sql string) एक बंद प्रश्नों को निष्पादित करने के लिए।

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

Answer 14

यदि आप sql फीचर्स का उपयोग करना चाहते हैं तो आप myBatis जैसे SQL मैपर फ्रेमवर्क का उपयोग कर सकते हैं।

Comments

यह वास्तव में इस तरह के मैपर का उपयोग करने के लाभों के बारे में जाब्ले के सवाल का जवाब नहीं है

— लुकास एडर