आधुनिक सूचना प्रौद्योगिकियां उनकी शक्ति से विस्मित होती हैं, वे उन अवसरों से अभिभूत होती हैं जो खुलते हैं, उनमें निहित तकनीकी पूर्णता से हतोत्साहित होते हैं, लेकिन एक अजीब बात है जिसके बारे में आईटी बार-बार अपने दांत तोड़ता है। डेटाबेस से उपयोगकर्ता डेटा दिखाएं, उससे इनपुट प्राप्त करें, इसे डेटाबेस में वापस डालें, परिणाम दिखाएं। इनपुट फ़ील्ड्स, बटन, चेक मार्क, शिलालेख - ऐसा लगता है कि वे इतने निषेधात्मक रूप से जटिल हो सकते हैं कि ट्रांसपिलर्स के शीर्ष पर चौखटे के ऊपर टेम्प्लेटिंग इंजन के शीर्ष पर फ्रेमवर्क जैसे पहेली निर्माण का निर्माण होगा? और क्यों, सभी जबरदस्त प्रयासों के बावजूद, हमारे पास यह तथ्य है कि ट्यूटोरियल में खिलौना के उदाहरण, निश्चित रूप से, आसानी से और सुखद रूप से बनाए जाते हैं, लेकिन जैसे ही टूलकिट वास्तविक जीवन के वास्तविक कार्यों का सामना करता है ... कैसे नरम कहा जाए ... हल करने के लिए कार्यों की जटिलता बढ़ने के साथ, एक मजबूत गैर-रैखिकता में वृद्धि होती है। कार्यान्वयन कठिनाइयों। खैर, यह सैद्धांतिक भौतिकी या अंतरिक्ष प्रौद्योगिकी के स्तर पर वास्तव में कुछ हैरान करने वाला होगा, क्योंकि वैसे भी - बटन और चेकमार्क नहीं हैं। यह बकवास नागरिकों के जीवन और दशकों तक सामूहिक कार्य करने के लिए क्यों जारी है?
कारण, शायद, हमेशा की तरह, कई हैं। संभवतः ये सभी एक तरह से या किसी अन्य पर विचार करने के योग्य हैं, लेकिन यहां और अब हम ऑब्जेक्ट-रिलेशनल मैपिंग (ओआरएम) कार्य के बारे में बात करेंगे, जो हमेशा किसी न किसी रूप में इन "बटन और चेकमार्क" के पीछे होता है।
हम ORM के बारे में क्या जानते हैं
- संबंधपरक तालिकाओं में डेटा संग्रहीत करना यह कहना नहीं है कि यह एक बहुत ही सरल मामला है, लेकिन सामान्य तौर पर विचार और इसके आवेदन के तरीके दोनों ही काफी स्पष्ट और अच्छी तरह से शोध किए गए हैं।
- ऑब्जेक्ट प्रोग्रामिंग के साथ, सब कुछ इतना अच्छा नहीं है (कई प्रतिस्पर्धी दृष्टिकोण हैं), लेकिन सामान्य तौर पर, प्रौद्योगिकियों के कार्यान्वयन और आवेदन के साथ, सब कुछ भी कम या ज्यादा स्पष्ट है।
- दोनों कि, और एक और - डेटा, उनके भंडारण और प्रसंस्करण के बारे में। यह वास्तव में, उसी चीज के बारे में है।
- यह हमारे लिए तर्कसंगत लगता है कि दो दुनियाओं के बीच एक सरल, समझने योग्य, सुविधाजनक, पूर्वानुमान और सार्वभौमिक पुल होना चाहिए।
- और हर बार हमें यह पुल आसानी से मिल जाता है, लेकिन दुर्भाग्य, इसकी सरलता, सुगमता, सुविधा, भविष्यवाणी और बहुमुखी प्रतिभा ट्यूटोरियल से सरल उदाहरणों से परे काम नहीं करते हैं।
- हर कोई पीड़ित होता है: डेवलपर्स, जिन्हें बहुत उबाऊ काम करना पड़ता है, और जिन उपयोगकर्ताओं को अनाड़ी सॉफ़्टवेयर और व्यापार से लड़ना पड़ता है, उनकी आवश्यकताओं की प्राप्ति अचानक असहनीय रूप से लंबी और महंगी हो जाती है, और एक पूरे के रूप में उद्योग।
- मैंने कई अलग-अलग ओआरएम देखे हैं, लेकिन किसी अच्छे को नहीं देखा है। यही है, एक, जो सरल उदाहरणों से परे है, एक बोझ और एक प्रोक्रिस्टियन बिस्तर में नहीं बदल जाता है।
सब कुछ इतना विचित्र क्यों है
संबंधपरक डेटाबेस के सिद्धांत और व्यवहार का वैचारिक आधार विधेय गणना है, जो कि गणित की एक शाखा है। ओओपी के लिए, एक समान वैचारिक आधार का अभाव है। कोई ओओपी के मूल विचार को इस तरह तैयार करने की कोशिश कर सकता है: चूंकि दुनिया वस्तुओं में शामिल है, इसलिए यह एक सॉफ्टवेयर सिस्टम के अंदर वस्तुओं का निर्माण करके इसे, इस दुनिया को मॉडल करना सुविधाजनक होगा। इस अर्थ में, एक बार में दो त्रुटियां। सबसे पहले, दुनिया खुद को शामिल नहीं करती है और कभी भी वस्तुओं में शामिल नहीं होती है। दूसरे, मुझे खेद है, लेकिन दुनिया को अनुकरण करने के लिए कार्यक्रम क्यों है? यही है, हमारे पास एक वैचारिक रूप से गलत बयान है, जो समस्या के एक अर्थहीन बयान से पूरी तरह से पूरक है।
प्रत्येक ORM स्पष्ट रूप से, बीच में एकीकृत पत्राचार को फैलाने का एक प्रयास है, वास्तव में, गणित की शाखा और विविध प्रथाओं का एक ढीला सेट, सुविधा के विचारों के आधार पर, ऐतिहासिक रूप से स्थापित दृष्टिकोण, और अक्सर किंवदंतियों पर भी, अधिकारियों की राय, और गलत धारणाएं। इन विट्रो में इसे काम करने के लिए बनाया जा सकता है, लेकिन विवो में दयनीय दिखने और खुशी से अधिक दुःख लाने के लिए बर्बाद किया गया है।
ऑब्जेक्ट ओरिएंटेशन की अनिवार्यता पर
फिर भी, हमारे सॉफ्टवेयर के ऑब्जेक्ट ओरिएंटेशन की आवश्यकता हमारी अपरिहार्य वास्तविकता है। यह अनिवार्यता मुख्य रूप से इस तथ्य पर आधारित है कि वस्तुओं के साथ काम करना हमारी किसी भी गतिविधि का सार और आधार है। दुनिया में वस्तुओं का समावेश नहीं है, लेकिन इस दुनिया में कुछ को समझने और इस दुनिया के साथ कुछ करने के लिए, हम खुद अपने हिस्से को वस्तुओं के रूप में घोषित करते हैं, उन्हें नाम कहते हैं, उनके व्यवहार को समझने की कोशिश करते हैं, उसे वांछित परिणाम प्राप्त करने का प्रयास करता है। यह हमारे कामकाज का तरीका है, और इसे छोड़ना असंभव है, और यह आवश्यक नहीं है। सब कुछ एक वस्तु है, इसलिए नहीं कि यह वास्तव में है, बल्कि इसलिए कि हम अन्यथा नहीं कर सकते। जो किसी भी तरह से एक वस्तु नहीं हो सकती है वह पूरी तरह से हमारी क्षमता को समझने की सीमा से बाहर है और हमारे प्रयासों के विषय के रूप में काम नहीं कर सकता है।
यहां तक कि अगर कार्यक्रम ओओपी तकनीकों के उपयोग के बिना लिखा जाता है, तो इसमें अनिवार्य रूप से ऑब्जेक्ट्स (शब्द के व्यापक अर्थ में) शामिल होते हैं, जिससे जोड़तोड़ करके डेवलपर अपनी समस्या हल करता है - चर, डेटा प्रकार, ऑपरेटर, एल्गोरिदम, वाक्य निर्माण, फ़ंक्शन, मॉड्यूल। उपयोगकर्ता के दृष्टिकोण से, कार्यक्रम में वस्तुओं का एक सेट भी होता है, जिसके साथ वह सहभागिता करता है - बटन, लेबल, इनपुट फ़ील्ड, पृष्ठ, साइटें और संपूर्ण सिस्टम।
हम अपने डेटाबेस में क्या स्टोर करते हैं
जैसा कि ऊपर उल्लेख किया गया है, रिलेशनल डेटाबेस विधेय गणना पर आधारित हैं। एक विधेय एक तथ्य है जो तैयार किया जाता है और, हमारे मामले में, एक माध्यम पर संग्रहीत होता है। बस के मामले में, मैं ध्यान देता हूं कि रिलेशनल डेटाबेस केवल विदेशी चाबियों द्वारा तालिकाओं के बीच संबंधों के बारे में इतना नहीं है। उचित शब्दावली में, संबंध वे हैं जिन्हें हम केवल टेबल कहते हैं। यही है, भले ही आपके डेटाबेस में केवल दो कॉलम (उदाहरण के लिए, नाम और फोन नंबर) के साथ एक तालिका है, आपके पास पहले से ही एक संबंधपरक डेटाबेस है जो दो सेटों के बीच संबंध स्थापित करता है, इस मामले में, नाम और फोन नंबर के सेट।
एक संबंधपरक डेटाबेस वस्तुओं को संग्रहीत नहीं करता है, यह तथ्यों को संग्रहीत करता है। संग्रहीत तथ्य, निश्चित रूप से, एक वस्तु है ("इस तथ्य के बारे में क्या है?"), और जब हम इस प्रश्न का उत्तर देने के लिए सिस्टम को सिखाने की कोशिश करते हैं, तो हमारे पास संस्थाएं हैं, अर्थात्, जिन वस्तुओं के साथ तथ्य जुड़े हैं। यदि आप सही तरीके से काम करते हैं, तो हमारे आधार की संरचना इस सवाल के जवाब की एक श्रृंखला से पैदा होती है कि "हम किस तरह के तथ्यों को रखने के लिए भेजते हैं?", और केवल अगले चरण में हमें कुछ ऐसा मिलता है जो वस्तुओं को वस्तु से समानता रखता है। आप निश्चित रूप से "वस्तुओं से" डिजाइन कर सकते हैं, लेकिन मैं ऐसा करने की सिफारिश नहीं करूंगा, जो कि डेटाबेस डिजाइन से सीधे संबंधित विषयों में प्रयोगशाला के काम को छोड़कर नहीं है। भारी वास्तुशिल्प गलतफहमी का खतरा बहुत बड़ा है। इसके अलावा, यह कम से कम असुविधाजनक है।
ऑब्जेक्ट डेटाबेस के बारे में एक छोटा सा विषयांतर। एक बहुत ही सरल विचार: यदि हम ORM के साथ समस्याओं से थक गए हैं, तो शायद हमें उस भाग के साथ कुछ करना चाहिए जो "R" है? हमारे डेटाबेस को एक कठिन और मांग से संबंधित राक्षस नहीं होने दें, लेकिन कुछ फैशनेबल युवा विशेष रूप से वस्तुओं को संग्रहीत करने के लिए तैयार हैं। उदाहरण के लिए, योजनाबद्ध NoSQL-base के कुछ प्रकार। लेकिन अंत में यह अचानक पता चला कि NoSQL की तरह ORM भी पुराने पुराने SQL- वाले की तुलना में अधिक अजीब और अप्राकृतिक हैं। वैसे भी, हम सर्किट-मुक्त डीबीएमएस संचालित करने के लिए और खुशी के साथ हो सकते हैं, लेकिन प्रकृति में सर्किट-मुक्त डेटा नहीं हैं। सर्किटलेस डेटाबेस के लिए ORM से अधिक असहाय, गैर जिम्मेदार और अनैतिक कुछ भी नहीं है।
अच्छा ORM
एक अच्छा ओआरएम लापता ओआरएम है। खैर, गंभीरता से। अपने किसी भी ORM सिस्टम को देखें और ईमानदारी से अपने प्रश्न का उत्तर देने का प्रयास करें: इस राक्षस के क्या लाभ हैं? ख़ुशियों के अधूरे वादों और बार-बार बदनाम हुए अपनों को छोड़कर इसके इस्तेमाल की वजह क्या है? बेशक, कुछ उपयोगी उपयोगी चीजें हैं, लेकिन वे पेश किए गए वास्तु विकृति और प्रदर्शन समस्याओं की पृष्ठभूमि के खिलाफ क्या हैं जो लगातार नीले रंग से उत्पन्न होती हैं?
एक नियम के रूप में, "निम्न-स्तरीय" डेटाबेस एपीआई सरल, सुविधाजनक, पूर्ण और सुसंगत है। आमतौर पर सभी सुविधाओं को सूचीबद्ध करने के लिए पर्याप्त उंगलियां। उन्हें सीखने के लिए एक ईश्वर समाचार नहीं है जो एक कार्य है।
मैं उन वास्तु सिद्धांतों के एक सेट को स्केच करने की कोशिश करूँगा जो आपको ORM का उपयोग किए बिना डेटाबेस में वस्तुओं को मैप करने की अनुमति देते हैं:
- हम तथ्यों को संग्रहीत करते हैं, वस्तुओं पर काम करते हैं। याद रखें कि डेटाबेस तथ्यों को संग्रहीत करता है, और डेटा प्रोसेसिंग में शामिल ऑब्जेक्ट मॉडल विभिन्न बिंदुओं से तथ्यों के सेट के अनुमान हैं। उदाहरण के लिए, नामों और फोन नंबरों के साथ दिए गए उदाहरण के लिए, हमारे पास एबनेमर क्लास हो सकता है, जिसके लिए कई नंबर स्टोर किए जा सकते हैं, और फोननंबर क्लास भी, जिसके लिए कई सब्सक्राइबर सेट किए जा सकते हैं (यह मत भूलिए कि पर्सनल मोबाइल नंबरों के अलावा, हम जहां अभी भी अपार्टमेंट और कार्यालय फोन हैं)। और डेटाबेस में तालिका सिर्फ एक है जो कई नामों और फोन नंबर के बीच कई-से-कई संबंधों को परिभाषित करती है। बस दो अलग-अलग अनुमान। यह दृष्टिकोण, वैसे, आम तौर पर बहुत अधिक जटिल मामलों को मापता है, जिससे आपको सिस्टम में ऐसी उपयोगी कक्षाएं मिल सकती हैं, उदाहरण के लिए, "मानदंडों के दिए गए संयोजन के अनुसार किसी दिए गए अवधि के लिए औसत बिक्री।"
- तथ्यों को एक समस्या उन्मुख एपीआई के माध्यम से वस्तुओं और इसके विपरीत में अनुमानित किया जाता है। एक समाधान लागू किए बिना जो सार्वभौमिक होने का दावा करता है। यदि आप अभी भी सुविधाजनक एपीआई की रचना करना नहीं जानते हैं, तो जानें कि कैसे। और महत्वपूर्ण बात, अपने आप को उन्हें तुरंत दस्तावेज़ करना सिखाएं।
- सब से ऊपर का आदेश। यदि आप किसी कठोर डेटा योजना के साथ DBMS के क्लासिक संस्करण का उपयोग करते हैं, तो यह योजना अपने आप में डेटा के साथ कार्य करने के लिए आदेश लाती है। वस्तुओं की संरचना द्वारा एन्कोडेड अतिरिक्त संरचना केवल बेमानी है। यदि आप एक स्कीमा-मुक्त डीबीएमएस का उपयोग करते हैं, तो निश्चित रूप से आपको यह सुनिश्चित करने के लिए कुछ प्रयास करने होंगे कि आपका डेटाबेस कूड़े के पहाड़ में न बदल जाए क्योंकि विभिन्न डेवलपर्स के पास अलग-अलग विचार हैं जो संग्रहीत हैं।
- DBMS स्वतंत्रता (यदि आवश्यक हो)। यदि आपके लिए ORM की सबसे दिलचस्प संपत्ति DBMS स्वतंत्रता है, तो ODBC, JDBC, ADO जैसे विशेष उपकरणों का उपयोग करें, या यदि यह संभव नहीं है, तो अपना खुद का स्तर बनाएं। यह उतना मुश्किल नहीं है जितना कि यह पहले लग सकता है। आपको अपने कार्य के लिए बिल्कुल सभी DBMS की सभी क्षमताओं के लिए समर्थन की आवश्यकता नहीं है, है ना?
- डेटा के साथ काम करने के अतिरिक्त पहलुओं के बारे में मत भूलना। जैसे, उदाहरण के लिए, डेटा तक पहुंच साझा करना (जो मनमाने ढंग से जटिल हो सकता है), निगरानी, प्रतिकृति और बहुत कुछ। लेकिन यहां मेरे लिए आपके लिए अच्छी खबर है: क्योंकि आपके पसंदीदा ओआरएम में, ऐड। पहलू अभी भी सिद्धांत के अनुसार लागू किया जाता है "आप सभी को खुश नहीं करेंगे, जो आप खाते हैं उसे खाएं", एक संदिग्ध सेवा की अस्वीकृति जिसे आपको सहयोग से अधिक से निपटना होगा अंततः एक रणनीतिक रूप से सही निर्णय साबित होगा।
कुल मिलाकर
ORM हमारे उद्योग के लिए एक बहुत ही गंभीर विषय है। एक ऐसे युग में जब क्लाउड आर्टिफिशियल इंटेलिजेंस क्वांटम ब्लॉकचेन की जुताई करता है, अधिकांश कार्यबल व्यापार तर्क और डेटाबेस के लिए एक उपयोगकर्ता इंटरफ़ेस खराब करने में व्यस्त है। इस रचनात्मक प्रक्रिया में हर जगह सूक्ष्म कोड, सूक्ष्मदर्शी, दर्द और निराशा के साथ फैली हुई लाखों लाइनें हैं। इस दुख की स्थिति की जड़ों में से एक अत्यंत लगातार गलत धारणा है जो एक सार्वभौमिक ओआरएम सिद्धांत रूप में संभव है। लेकिन यह असंभव है, और इसके लिए एक बुनियादी कारण है, जिसे समाप्त नहीं किया जा सकता है। इस तथ्य के बारे में जागरूकता इस दुःस्वप्न से बाहर निकलने की दिशा में पहला कदम है। एक रास्ता है, विकल्प हैं, लेकिन पहले आपको ध्यान का ध्यान रखने के लिए महसूस करने, महसूस करने और सीखने की आवश्यकता है।
PS मैं ईमानदारी से पेशे से उन भाइयों से माफी माँगता हूँ जिन्होंने ORM की दुनिया में कई सार्वभौमिक सर्वश्रेष्ठ बनाने में बहुत समय और प्रयास लगाया है। मुझे वास्तव में खेद है।