ORM या ऑब्जेक्ट रिलेशनल प्रोजेक्टर

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

एक डेटाबेस को छिपाना या एक साँप के साथ एक हाथी को कैसे पार करना है

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

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


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

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

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

पुस्तक के भाग के रूप में ऑब्जेक्ट-रिलेशनल प्रोजेक्शन टूल की समीक्षा की योजना नहीं बनाई गई थी। वे पहले से ही नेट पर पर्याप्त हैं, जिनमें से मेरा एक छोटा भी शामिल है, 2005 में वापस आ गया, लेकिन बहुत पुराना नहीं है। इसलिए, निम्नलिखित उदाहरण मुख्य रूप से NHibernate ढांचे की चिंता करेंगे।

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

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

एसक्यूएल जावा या सी # के विपरीत चौथी पीढ़ी की उच्च-स्तरीय घोषित विशेषीकृत भाषा है, जो अभी भी तीसरी पीढ़ी की अनिवार्य भाषाओं में है। तीन दर्जन लाइनों के लिए एकमात्र एसक्यूएल स्टेटमेंट, जो कुंजी चयन की तुलना में कुछ अधिक जटिल प्रदर्शन करता है, उसी परिणाम को प्राप्त करने के लिए, सी # में अधिक लाइनों की आवश्यकता नहीं होने पर, कई की आवश्यकता होगी।

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

अन्यथा, एप्लिकेशन प्रोग्रामर को डेटाबेस से निकालने के लिए और उसके बाद सीधे अपने एप्लिकेशन में बड़ी मात्रा में डेटा को संसाधित करने के लिए बर्बाद किया जाता है। उसी तरह, 80 के दशक के अंत में क्लिपर के शुरुआती संस्करणों पर डेवलपर्स द्वारा एम्बेडेड SQL की अनुपस्थिति में टेबल डेटा संसाधित किया गया था। वहां इसे "नेविगेशन प्रसंस्करण" कहा जाता था। मुझे लगता है कि यह शब्द यहां प्रासंगिक है।

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

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

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

हाइबरनेट प्रकार ओआरएम द्वारा प्रदान किए गए सार की मोटी परत के बावजूद, ऑर्थोगोनल दुनिया और एसक्यूएल भाषा के प्रासंगिक सिद्धांतों के ज्ञान के बिना आरडीबीएमएस के साथ प्रभावी ढंग से एक आवेदन कार्य करना लगभग असंभव है।

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

हमेशा की तरह ORM का उपयोग करें

सॉफ़्टवेयर निर्माण प्रस्तुतियों में, प्रस्तुति परतों, व्यावसायिक तर्क और संग्रहीत डेटा को अलग करने के लिए अक्सर सुंदर योजनाएं तैयार की जाती हैं। नौसिखिए प्रोग्रामर का नीला सपना सभी परतों को विकसित करने के लिए केवल एक वातावरण और भाषा का उपयोग करना है और संबंधपरक डीबीएमएस के ज्ञान की आवश्यकता के बारे में भूल जाना, उनके उद्देश्य को एक प्रकार की "बौद्धिक फाइल सिस्टम" को कम करना है। शब्द SQL कुछ प्राचीन से जुड़े नकारात्मक संघों को उद्घाटित करता है, ट्रिगर या संग्रहीत प्रक्रियाओं का उल्लेख नहीं करने के लिए। अच्छे लोग क्षितिज पर दिखाई देते हैं, हाथ के नीचे डोमेन-उन्मुख विकास के बारे में विभिन्न गुरुओं की पुस्तकों के साथ, नए लोगों को कुछ इस तरह से बताते हुए: “दोस्तों, संबंधपरक डीबीएमएस 30 साल पहले के एक लंबी अवधि के अवशेष हैं। अब सब कुछ OOP पर बनाया गया है। और एक अद्भुत बात है - ओआरएम। इसका उपयोग करना शुरू करें और अतीत की कठिन विरासत को भूल जाएं! ”

लोग प्रस्ताव स्वीकार करते हैं। इसके अलावा, सिस्टम डेवलपमेंट का विकास इस प्रकार है।
सबसे पहले, प्रदर्शित करने के लिए ORM ढांचे का चयन किया जाता है। पहले से ही इस स्तर पर, यह पता चला है कि सिद्धांत और मानकों के साथ स्थिति खराब है। यह सावधान रहना ठीक होगा, लेकिन एक प्रस्तुति यह दिखाती है कि 10 मिनट में आप एक आवेदन का आधार कैसे बना सकते हैं जैसे कि संपर्क नोटबुक आकर्षक है। हल!

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

एक बार जब डेवलपर्स ने सीआरयूडी तर्क लागू कर दिया है, तो मुख्य कार्रवाई शुरू होती है। सीक्वल का उपयोग करना अब मुश्किल है। DBMSs के बीच प्रदर्शन रणनीतियों और अनुप्रयोग पोर्टेबिलिटी समस्याओं को छूने के बिना, वास्तव में, कनेक्शन के साथ प्रत्येक SQL क्वेरी, एक डोमेन के लिए बढ़ी है, इस अवसर के लिए बनाए गए वर्ग पर तालिका परिणाम के एक विशिष्ट प्रक्षेपण के साथ है। इसलिए, आपको अपनी स्वयं की ORM क्वेरी भाषा का उपयोग करना होगा। गैर-मानक, डिबगिंग और प्रोफाइलिंग टूल के बिना। यदि वह, भाषा, आमतौर पर इस ओआरएम में उपलब्ध है। जो लोग उपयुक्त एकीकरण का समर्थन करते हैं, उनके लिए .NET वातावरण LINQ का उपयोग करना संभव बनाता है, जो आपको संकलन स्तर पर कुछ त्रुटियों को पकड़ने की अनुमति देता है।

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

एसक्यूएल

SELECT * FROM task_queue WHERE id_task IN (2, 3, 15) AND id_task_origin = 10 

NHibernate HQL

 IList<TaskQueue> queues = session .CreateQuery("from TaskQueue where Task.Id in (2, 3, 15) and TaskOrigin.Id = 10") .List<TaskQueue>(); 

मानदंड के साथ HQL के बिना NHibernate

 IList<TaskQueue> queues = session.CreateCriteria() .Add(Expression.In("Task.Id", someTasks.ToArray())) .Add(Expression.Eq("TaskOrigin.Id", 10)) .List<TaskQueue>(); 

LINQ (NHibernate)

 IList<TaskQueue> queues = session .Query<TaskQueue>() .Where(q => someTasks.Contains(q.Task.Id) && q.TaskOrigin.Id == 10).ToList(); 

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

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