वस्तु-संबंधपरक प्रतिबाधा बेमेल: Difference between revisions
No edit summary |
No edit summary |
||
| Line 53: | Line 53: | ||
*स्थैतिक प्रकार की "सुरक्षा" जांच का अभाव। टाइप किए गए ्सेसर्स का उपयोग कभी-कभी इसे कम करने के तरीके के रूप में किया जाता है। | *स्थैतिक प्रकार की "सुरक्षा" जांच का अभाव। टाइप किए गए ्सेसर्स का उपयोग कभी-कभी इसे कम करने के तरीके के रूप में किया जाता है। | ||
* रनटाइम निर्माण और पहुंच की संभावित प्रदर्शन लागत। | * रनटाइम निर्माण और पहुंच की संभावित प्रदर्शन लागत। | ||
* [[ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में बहुरूपता]] जैसे विशिष्ट OO पहलुओं का मूल रूप से उपयोग करने में | * [[ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में बहुरूपता]] जैसे विशिष्ट OO पहलुओं का मूल रूप से उपयोग करने में असमर्थता होती हैं। | ||
=== मुआवजा === | === मुआवजा === | ||
| Line 68: | Line 68: | ||
प्रतिबाधा बेमेल [[डोमेन ऑब्जेक्ट]] और उपयोगकर्ता इंटरफ़ेस के बीच प्रोग्रामिंग में है। ऑपरेटरों, प्रबंधकों और अन्य गैर-प्रोग्रामरों को डेटाबेस में रिकॉर्ड तक पहुंचने और हेरफेर करने की अनुमति देने के लिए परिष्कृत उपयोगकर्ता इंटरफ़ेस के लिए अक्सर विभिन्न डेटाबेस विशेषताओं (नाम और प्रकार से परे) की प्रकृति के बारे में गहन ज्ञान की आवश्यकता होती है। विशेष रूप से, उपयोगकर्ता इंटरफ़ेस को डिज़ाइन करना अच्छा अभ्यास माना जाता है (अंतिम-उपयोगकर्ता उत्पादकता के दृष्टिकोण से) ताकि यूआई अवैध लेनदेन (जो डेटाबेस बाधा का उल्लंघन करते हैं) को प्रवेश करने से रोक सके; ऐसा करने के लिए [[कोड दोहराव]] रिलेशनल स्कीमाटा में मौजूद अधिकांश तर्क को कोड में डुप्लिकेट करने की आवश्यकता होती है। | प्रतिबाधा बेमेल [[डोमेन ऑब्जेक्ट]] और उपयोगकर्ता इंटरफ़ेस के बीच प्रोग्रामिंग में है। ऑपरेटरों, प्रबंधकों और अन्य गैर-प्रोग्रामरों को डेटाबेस में रिकॉर्ड तक पहुंचने और हेरफेर करने की अनुमति देने के लिए परिष्कृत उपयोगकर्ता इंटरफ़ेस के लिए अक्सर विभिन्न डेटाबेस विशेषताओं (नाम और प्रकार से परे) की प्रकृति के बारे में गहन ज्ञान की आवश्यकता होती है। विशेष रूप से, उपयोगकर्ता इंटरफ़ेस को डिज़ाइन करना अच्छा अभ्यास माना जाता है (अंतिम-उपयोगकर्ता उत्पादकता के दृष्टिकोण से) ताकि यूआई अवैध लेनदेन (जो डेटाबेस बाधा का उल्लंघन करते हैं) को प्रवेश करने से रोक सके; ऐसा करने के लिए [[कोड दोहराव]] रिलेशनल स्कीमाटा में मौजूद अधिकांश तर्क को कोड में डुप्लिकेट करने की आवश्यकता होती है। | ||
कुछ कोड-विकास ढाँचे डेटाबेस के स्कीमा (जैसे संदर्भात्मक अखंडता बाधाएं) में दर्शाए गए तर्क के कुछ रूपों का लाभ उठा सकते हैं, ताकि ऐसे मुद्दों को किसी मामले पर लिखे गए तदर्थ कोड के बजाय लाइब्रेरी रूटीन के माध्यम से सामान्य और मानक फैशन में | कुछ कोड-विकास ढाँचे डेटाबेस के स्कीमा (जैसे संदर्भात्मक अखंडता बाधाएं) में दर्शाए गए तर्क के कुछ रूपों का लाभ उठा सकते हैं, ताकि ऐसे मुद्दों को किसी मामले पर लिखे गए तदर्थ कोड के बजाय लाइब्रेरी रूटीन के माध्यम से सामान्य और मानक फैशन में नियंत्रितजा सके। -मामला-दर-मामला आधार। | ||
=== SQL-विशिष्ट प्रतिबाधा और समाधान === | === SQL-विशिष्ट प्रतिबाधा और समाधान === | ||
यह तर्क दिया गया है कि SQL, डोमेन प्रकारों के बहुत सीमित सेट (और अन्य कथित त्रुटियों) के कारण उचित ऑब्जेक्ट और डोमेन-मॉडलिंग को कठिन बना देता है; और यह कि SQL DBMS और एप्लिकेशन प्रोग्राम (चाहे ऑब्जेक्ट-ओरिएंटेड शैली में लिखा गया हो या नहीं) के बीच बहुत ही हानिपूर्ण और अकुशल इंटरफ़ेस बनाता है। हालाँकि, SQL वर्तमान में बाज़ार में मात्र व्यापक रूप से स्वीकृत सामान्य डेटाबेस भाषा है''';''' विक्रेता-विशिष्ट क्वेरी भाषाओं का उपयोग टाले जाने योग्य होने पर खराब अभ्यास के रूप में देखा जाता है। अन्य डेटाबेस भाषाएँ जैसे [[बिजनेस सिस्टम 12]] और ट्यूटोरियल डी प्रस्तावित की गई हैं; लेकिन इनमें से किसी को भी डीबीएमएस विक्रेताओं द्वारा व्यापक रूप से नहीं अपनाया गया है। | |||
Oracle और Microsoft SQL सर्वर जैसे मुख्यधारा ऑब्जेक्ट-रिलेशनल DBMS के वर्तमान संस्करणों में, उपरोक्त बिंदु गैर-मुद्दा हो सकता है। इन इंजनों के साथ, किसी दिए गए डेटाबेस की कार्यक्षमता को आधुनिक OO भाषा (Oracle के लिए Java, और SQL सर्वर के लिए Microsoft .NET भाषा) में लिखे गए संग्रहीत कोड (फ़ंक्शन और प्रक्रियाओं) के माध्यम से मनमाने ढंग से बढ़ाया जा सकता है, और इन कार्यों को लागू किया जा सकता है SQL कथनों को पारदर्शी तरीके से इन-टर्न करें: अर्थात, उपयोगकर्ता को न तो पता है और न ही इसकी परवाह है कि ये फ़ंक्शन/प्रक्रियाएँ मूल रूप से डेटाबेस इंजन का हिस्सा नहीं थीं। आधुनिक सॉफ्टवेयर-विकास प्रतिमान पूरी तरह से समर्थित हैं: इस प्रकार, कोई लाइब्रेरी रूटीन का सेट बना सकता है जिसे कई डेटाबेस स्कीमा में पुन: उपयोग किया जा सकता | Oracle और Microsoft SQL सर्वर जैसे मुख्यधारा ऑब्जेक्ट-रिलेशनल DBMS के वर्तमान संस्करणों में, उपरोक्त बिंदु गैर-मुद्दा हो सकता है। इन इंजनों के साथ, किसी दिए गए डेटाबेस की कार्यक्षमता को आधुनिक OO भाषा (Oracle के लिए Java, और SQL सर्वर के लिए Microsoft .NET भाषा) में लिखे गए संग्रहीत कोड (फ़ंक्शन और प्रक्रियाओं) के माध्यम से मनमाने ढंग से बढ़ाया जा सकता है, और इन कार्यों को लागू किया जा सकता है SQL कथनों को पारदर्शी तरीके से इन-टर्न करें: अर्थात, उपयोगकर्ता को न तो पता है और न ही इसकी परवाह है कि ये फ़ंक्शन/प्रक्रियाएँ मूल रूप से डेटाबेस इंजन का हिस्सा नहीं थीं। आधुनिक सॉफ्टवेयर-विकास प्रतिमान पूरी तरह से समर्थित हैं: इस प्रकार, कोई लाइब्रेरी रूटीन का सेट बना सकता है जिसे कई डेटाबेस स्कीमा में पुन: उपयोग किया जा सकता है | ||
इन विक्रेताओं ने DBMS बैक-एंड पर OO-भाषा | इन विक्रेताओं ने DBMS बैक-एंड पर OO-भाषा एकीकरण का समर्थन करने का निर्णय लिया क्योंकि उन्हें एहसास हुआ कि, SQL में प्रक्रियात्मक निर्माणों को जोड़ने के लिए ISO SQL-99 समिति के प्रयासों के बावजूद, SQL में पुस्तकालयों और डेटा संरचनाओं का समृद्ध सेट कभी नहीं होगा। आज के एप्लिकेशन प्रोग्रामर इसे हल्के में लेते हैं, और मुख्य SQL भाषा का विस्तार करने का प्रयास करने के बजाय इनका यथासंभव सीधे लाभ उठाना उचित है। नतीजतन, "एप्लिकेशन प्रोग्रामिंग" और "डेटाबेस प्रशासन" के बीच का अंतर अब धुंधला हो गया है: बाधाओं और ट्रिगर्स जैसी सुविधाओं के मजबूत कार्यान्वयन के लिए अक्सर दोहरे डीबीए/ओओ-प्रोग्रामिंग कौशल वाले व्यक्ति या इन कौशलों को संयोजित करने वाले व्यक्तियों के बीच साझेदारी की आवश्यकता हो सकती है। . यह तथ्य नीचे दिए गए "जिम्मेदारी के विभाजन" मुद्दे पर भी लागू होता है। | ||
हालाँकि, कुछ लोग यह कहेंगे कि यह विवाद इस तथ्य के कारण विवादास्पद है कि: (1) आरडीबीएमएस का उद्देश्य कभी भी ऑब्जेक्ट मॉडलिंग की सुविधा प्रदान करना नहीं था, और (2) एसक्यूएल को आम तौर पर केवल हानिपूर्ण या अक्षम इंटरफ़ेस भाषा के रूप में देखा जाना चाहिए जब कोई हो ऐसा समाधान प्राप्त करने का प्रयास किया जा रहा है जिसके लिए RDBMSes डिज़ाइन नहीं किए गए थे। SQL वह काम करने में बहुत कुशल है जिसके लिए इसे डिज़ाइन किया गया था, अर्थात् डेटा के बड़े सेट को क्वेरी करना, सॉर्ट करना, फ़िल्टर करना और संग्रहीत करना। कुछ लोग अतिरिक्त रूप से इंगित करेंगे कि बैक-एंड में ओओ भाषा कार्यक्षमता को शामिल करने से खराब वास्तुशिल्प अभ्यास की सुविधा मिलती है, क्योंकि यह आरडीबीएमएस के विपरीत, डेटा स्तर में उच्च स्तरीय एप्लिकेशन तर्क को स्वीकार करता है। | हालाँकि, कुछ लोग यह कहेंगे कि यह विवाद इस तथ्य के कारण विवादास्पद है कि: (1) आरडीबीएमएस का उद्देश्य कभी भी ऑब्जेक्ट मॉडलिंग की सुविधा प्रदान करना नहीं था, और (2) एसक्यूएल को आम तौर पर केवल हानिपूर्ण या अक्षम इंटरफ़ेस भाषा के रूप में देखा जाना चाहिए जब कोई हो ऐसा समाधान प्राप्त करने का प्रयास किया जा रहा है जिसके लिए RDBMSes डिज़ाइन नहीं किए गए थे। SQL वह काम करने में बहुत कुशल है जिसके लिए इसे डिज़ाइन किया गया था, अर्थात् डेटा के बड़े सेट को क्वेरी करना, सॉर्ट करना, फ़िल्टर करना और संग्रहीत करना। कुछ लोग अतिरिक्त रूप से इंगित करेंगे कि बैक-एंड में ओओ भाषा कार्यक्षमता को शामिल करने से खराब वास्तुशिल्प अभ्यास की सुविधा मिलती है, क्योंकि यह आरडीबीएमएस के विपरीत, डेटा स्तर में उच्च स्तरीय एप्लिकेशन तर्क को स्वीकार करता है। | ||
| Line 83: | Line 83: | ||
=== उत्तरदायित्व का विभाजन === | === उत्तरदायित्व का विभाजन === | ||
विवाद का अन्य मुद्दा एप्लिकेशन प्रोग्रामर और [[ डेटाबेस प्रशासक |डेटाबेस प्रशासक]] (डीबीए) के बीच जिम्मेदारी का उचित विभाजन है। अक्सर ऐसा होता है कि एप्लिकेशन कोड में आवश्यक बदलावों के लिए (अनुरोधित नई सुविधा या कार्यक्षमता को लागू करने के लिए) डेटाबेस परिभाषा में संबंधित बदलावों की आवश्यकता होती है; अधिकांश संगठनों में, डेटाबेस परिभाषा डीबीए की ज़िम्मेदारी है। उत्पादन डेटाबेस प्रणाली को 24 घंटे बनाए रखने की आवश्यकता के कारण कई डीबीए डेटाबेस स्कीमाटा में ऐसे बदलाव करने के लिए अनिच्छुक हैं जिन्हें वे अनावश्यक या अनावश्यक मानते हैं और कुछ मामलों में ऐसा करने से सीधे इनकार कर देते हैं। विकासात्मक डेटाबेस का उपयोग (उत्पादन प्रणालियों के अलावा) कुछ हद तक मदद कर सकता है; लेकिन जब नया विकसित एप्लिकेशन लाइव होगा तो डीबीए को किसी भी बदलाव को मंजूरी देने की आवश्यकता होगी। कुछ प्रोग्रामर इसे अकर्मण्यता के रूप में देखते हैं; हालाँकि, यदि डेटाबेस परिभाषा में कोई भी बदलाव उत्पादन प्रणाली में सेवा की हानि का कारण बनता है, तो डीबीए को अक्सर जिम्मेदार ठहराया जाता है - परिणामस्वरूप, कई डीबीए एप्लिकेशन कोड में डिज़ाइन परिवर्तन शामिल करना पसंद करते हैं, जहां डिज़ाइन दोषों के भयावह परिणाम होने की संभावना बहुत कम होती है। | विवाद का अन्य मुद्दा एप्लिकेशन प्रोग्रामर और [[ डेटाबेस प्रशासक |डेटाबेस प्रशासक]] (डीबीए) के बीच जिम्मेदारी का उचित विभाजन है। अक्सर ऐसा होता है कि एप्लिकेशन कोड में आवश्यक बदलावों के लिए (अनुरोधित नई सुविधा या कार्यक्षमता को लागू करने के लिए) डेटाबेस परिभाषा में संबंधित बदलावों की आवश्यकता होती है; अधिकांश संगठनों में, डेटाबेस परिभाषा डीबीए की ज़िम्मेदारी है। उत्पादन डेटाबेस प्रणाली को 24 घंटे बनाए रखने की आवश्यकता के कारण कई डीबीए डेटाबेस स्कीमाटा में ऐसे बदलाव करने के लिए अनिच्छुक हैं जिन्हें वे अनावश्यक या अनावश्यक मानते हैं और कुछ मामलों में ऐसा करने से सीधे इनकार कर देते हैं। विकासात्मक डेटाबेस का उपयोग (उत्पादन प्रणालियों के अलावा) कुछ हद तक मदद कर सकता है; लेकिन जब नया विकसित एप्लिकेशन लाइव होगा तो डीबीए को किसी भी बदलाव को मंजूरी देने की आवश्यकता होगी। कुछ प्रोग्रामर इसे अकर्मण्यता के रूप में देखते हैं; हालाँकि, यदि डेटाबेस परिभाषा में कोई भी बदलाव उत्पादन प्रणाली में सेवा की हानि का कारण बनता है, तो डीबीए को अक्सर जिम्मेदार ठहराया जाता है - परिणामस्वरूप, कई डीबीए एप्लिकेशन कोड में डिज़ाइन परिवर्तन शामिल करना पसंद करते हैं, जहां डिज़ाइन दोषों के भयावह परिणाम होने की संभावना बहुत कम होती है। | ||
हालांकि, डीबीए और डेवलपर्स के बीच गैर-अकार्यात्मक संबंध वाले संगठनों में, उपरोक्त मुद्दा खुद को प्रस्तुत नहीं करना चाहिए, क्योंकि डेटाबेस स्कीमा को बदलने या न करने का निर्णय केवल व्यावसायिक जरूरतों से प्रेरित होगा: अतिरिक्त डेटा को बनाए रखने के लिए नई आवश्यकता या ए उदाहरण के लिए, महत्वपूर्ण एप्लिकेशन के प्रदर्शन को बढ़ावा देने से स्कीमा संशोधन शुरू हो जाएगा। | हालांकि, डीबीए और डेवलपर्स के बीच गैर-अकार्यात्मक संबंध वाले संगठनों में, उपरोक्त मुद्दा खुद को प्रस्तुत नहीं करना चाहिए, क्योंकि डेटाबेस स्कीमा को बदलने या न करने का निर्णय केवल व्यावसायिक जरूरतों से प्रेरित होगा: अतिरिक्त डेटा को बनाए रखने के लिए नई आवश्यकता या ए उदाहरण के लिए, महत्वपूर्ण एप्लिकेशन के प्रदर्शन को बढ़ावा देने से स्कीमा संशोधन शुरू हो जाएगा। | ||
==दार्शनिक मतभेद == | ==दार्शनिक मतभेद == | ||
OO और संबंधपरक मॉडल के बीच प्रमुख दार्शनिक अंतरों को निम्नानुसार संक्षेपित किया जा सकता है | OO और संबंधपरक मॉडल के बीच प्रमुख दार्शनिक अंतरों को निम्नानुसार संक्षेपित किया जा सकता है | | ||
* घोषणात्मक बनाम अनिवार्य इंटरफेस{{snd}} संबंधपरक सोच डेटा को इंटरफ़ेस के रूप में उपयोग करती है, व्यवहार को इंटरफ़ेस के रूप में नहीं। इस प्रकार इसमें ओओ के व्यवहारिक झुकाव के विपरीत डिजाइन दर्शन में घोषणात्मक झुकाव है। (कुछ संबंधपरक प्रस्तावक जटिल व्यवहार प्रदान करने के लिए ट्रिगर्स, संग्रहीत प्रक्रियाओं आदि का उपयोग करने का सुझाव देते हैं, लेकिन यह सामान्य दृष्टिकोण नहीं है।) | * '''घोषणात्मक बनाम अनिवार्य इंटरफेस{{snd}}''' संबंधपरक सोच डेटा को इंटरफ़ेस के रूप में उपयोग करती है, व्यवहार को इंटरफ़ेस के रूप में नहीं। इस प्रकार इसमें ओओ के व्यवहारिक झुकाव के विपरीत डिजाइन दर्शन में घोषणात्मक झुकाव है। (कुछ संबंधपरक प्रस्तावक जटिल व्यवहार प्रदान करने के लिए ट्रिगर्स, संग्रहीत प्रक्रियाओं आदि का उपयोग करने का सुझाव देते हैं, लेकिन यह सामान्य दृष्टिकोण नहीं है।) | ||
* स्कीमा | *'''स्कीमा बाउंड''' '''-''' ऑब्जेक्ट को "पैरेंट स्कीमा" का पालन करने की आवश्यकता नहीं होती है जिसके लिए किसी ऑब्जेक्ट के गुण या एक्सेसर्स होते हैं, जबकि तालिका पंक्तियों को इकाई की स्कीमा का पालन करना होगा। दी गई पंक्ति और केवल इकाई से संबंधित होनी चाहिए। OO में निकटतम चीज़ वंशानुक्रम है, लेकिन यह आम तौर पर पेड़ के आकार का और वैकल्पिक है। गतिशील डेटाबेस प्रणालियाँ जो तदर्थ स्तंभों की अनुमति देती हैं, स्कीमा बाध्यता को शिथिल कर सकती हैं, लेकिन ऐसी प्रणालियाँ या तो वर्तमान में दुर्लभ हैं, या "संबंधपरक" के रूप में उनका वर्गीकरण प्रश्न में है। | ||
* प्रवेश नियम{{snd}} रिलेशनल डेटाबेस में, विशेषताओं को पूर्वनिर्धारित रिलेशनल ऑपरेटरों के माध्यम से | * '''प्रवेश नियम{{snd}}''' रिलेशनल डेटाबेस में, विशेषताओं को पूर्वनिर्धारित रिलेशनल ऑपरेटरों के माध्यम से एक्सेस और परिवर्तित किया जाता है, जबकि OO प्रत्येक वर्ग को अपना स्वयं का राज्य परिवर्तन इंटरफ़ेस और अभ्यास बनाने की अनुमति देता है। OO का स्व-संचालन संज्ञा दृष्टिकोण प्रत्येक वस्तु को स्वतंत्रता देता है जिसे संबंधपरक मॉडल अनुमति नहीं देता है। यह मानक बनाम स्थानीय स्वतंत्रता की बहस है। ओओ का तर्क है कि संबंधपरक मानक अभिव्यक्ति को सीमित करते हैं, जबकि संबंधपरक समर्थकों का सुझाव है कि नियम का पालन अधिक अमूर्त गणित जैसे तर्क, अखंडता और डिजाइन स्थिरता की अनुमति देता है। | ||
* संज्ञा और क्रिया के बीच संबंध{{snd}} OO क्रियाओं (क्रियाओं) और संज्ञाओं (संस्थाओं) के बीच मजबूत संबंध को प्रोत्साहित करता है, जिस पर परिचालन संचालित होता है। संज्ञा और क्रिया दोनों से युक्त परिणामी कसकर बंधी इकाई को आमतौर पर वर्ग (कंप्यूटर विज्ञान) कहा जाता है, या ओओ विश्लेषण में, संकल्पनात्मक मॉडल (कंप्यूटर विज्ञान) कहा जाता है। संबंधपरक डिज़ाइन आम तौर पर यह नहीं मानते हैं कि ऐसे तंग संघों (संबंधपरक ऑपरेटरों के बाहर) के बारे में कुछ भी प्राकृतिक या तार्किक है। | * '''संज्ञा और क्रिया के बीच संबंध{{snd}}''' OO क्रियाओं (क्रियाओं) और संज्ञाओं (संस्थाओं) के बीच मजबूत संबंध को प्रोत्साहित करता है, जिस पर परिचालन संचालित होता है। संज्ञा और क्रिया दोनों से युक्त परिणामी कसकर बंधी इकाई को आमतौर पर वर्ग (कंप्यूटर विज्ञान) कहा जाता है, या ओओ विश्लेषण में, संकल्पनात्मक मॉडल (कंप्यूटर विज्ञान) कहा जाता है। संबंधपरक डिज़ाइन आम तौर पर यह नहीं मानते हैं कि ऐसे तंग संघों (संबंधपरक ऑपरेटरों के बाहर) के बारे में कुछ भी प्राकृतिक या तार्किक है। | ||
*वस्तु की पहचान{{snd}} वस्तुओं (अपरिवर्तनीय को छोड़कर) को आम तौर पर विशिष्ट पहचान माना जाता है; दो वस्तुएँ जो निश्चित समय पर ही स्थिति में होती हैं, उन्हें समान नहीं माना जाता है। दूसरी ओर, संबंधों में इस प्रकार की पहचान की कोई अंतर्निहित अवधारणा नहीं होती है। जैसा कि कहा गया है, विश्व स्तर पर अद्वितीय [[उम्मीदवार कुंजी]] के उपयोग के माध्यम से डेटाबेस में रिकॉर्ड के लिए पहचान बनाना आम बात है; हालाँकि कई लोग इसे किसी भी डेटाबेस रिकॉर्ड के लिए ख़राब अभ्यास मानते हैं जिसका वास्तविक विश्व इकाई के साथ -से-एक पत्राचार नहीं होता है। (संबंध, वस्तुओं की तरह, पहचान उद्देश्यों के लिए बाहरी दुनिया में मौजूद होने पर डोमेन कुंजियों का उपयोग कर सकते हैं)। व्यवहार में संबंधपरक प्रणालियाँ स्थायी और निरीक्षण योग्य पहचान तकनीकों के लिए प्रयास करती हैं और उनका समर्थन करती हैं, जबकि वस्तु पहचान तकनीकें क्षणिक या स्थितिजन्य होती हैं। | *वस्तु की पहचान{{snd}} वस्तुओं (अपरिवर्तनीय को छोड़कर) को आम तौर पर विशिष्ट पहचान माना जाता है; दो वस्तुएँ जो निश्चित समय पर ही स्थिति में होती हैं, उन्हें समान नहीं माना जाता है। दूसरी ओर, संबंधों में इस प्रकार की पहचान की कोई अंतर्निहित अवधारणा नहीं होती है। जैसा कि कहा गया है, विश्व स्तर पर अद्वितीय [[उम्मीदवार कुंजी]] के उपयोग के माध्यम से डेटाबेस में रिकॉर्ड के लिए "पहचान" बनाना आम बात है; हालाँकि कई लोग इसे किसी भी डेटाबेस रिकॉर्ड के लिए ख़राब अभ्यास मानते हैं जिसका वास्तविक विश्व इकाई के साथ -से-एक पत्राचार नहीं होता है। (संबंध, वस्तुओं की तरह, पहचान उद्देश्यों के लिए बाहरी दुनिया में मौजूद होने पर डोमेन कुंजियों का उपयोग कर सकते हैं)। व्यवहार में संबंधपरक प्रणालियाँ स्थायी और निरीक्षण योग्य पहचान तकनीकों के लिए प्रयास करती हैं और उनका समर्थन करती हैं, जबकि वस्तु पहचान तकनीकें क्षणिक या स्थितिजन्य होती हैं। | ||
* सामान्यीकरण{{snd}} [[डेटाबेस सामान्यीकरण]] प्रथाओं को अक्सर OO डिज़ाइन द्वारा अनदेखा कर दिया जाता है। हालाँकि, यह OO की मूल विशेषता के बजाय केवल बुरी आदत हो सकती है। वैकल्पिक दृष्टिकोण यह है कि ऑब्जेक्ट का संग्रह, किसी प्रकार के पॉइंटर (कंप्यूटर प्रोग्रामिंग) के माध्यम से जुड़ा हुआ, [[नेटवर्क डेटाबेस]] के | * सामान्यीकरण{{snd}} [[डेटाबेस सामान्यीकरण]] प्रथाओं को अक्सर OO डिज़ाइन द्वारा अनदेखा कर दिया जाता है। हालाँकि, यह OO की मूल विशेषता के बजाय केवल बुरी आदत हो सकती है। वैकल्पिक दृष्टिकोण यह है कि ऑब्जेक्ट का संग्रह, किसी प्रकार के पॉइंटर (कंप्यूटर प्रोग्रामिंग) के माध्यम से जुड़ा हुआ, [[नेटवर्क डेटाबेस]] के समान है; जिसे बदले में अत्यंत असामान्य संबंधपरक डेटाबेस के रूप में देखा जा सकता है। | ||
* स्कीमा विरासत{{snd}} अधिकांश रिलेशनल डेटाबेस स्कीमा इनहेरिटेंस का समर्थन नहीं करते हैं। यद्यपि इस तरह की सुविधा को ओओपी के साथ संघर्ष को कम करने के लिए सिद्धांत में जोड़ा जा सकता है, संबंधपरक समर्थकों को पदानुक्रमित वर्गीकरण और उप-टाइपिंग की उपयोगिता पर विश्वास करने की कम संभावना है क्योंकि वे [[ समुच्चय सिद्धान्त | | * स्कीमा विरासत{{snd}} अधिकांश रिलेशनल डेटाबेस स्कीमा इनहेरिटेंस का समर्थन नहीं करते हैं। यद्यपि इस तरह की सुविधा को ओओपी के साथ संघर्ष को कम करने के लिए सिद्धांत में जोड़ा जा सकता है, संबंधपरक समर्थकों को पदानुक्रमित वर्गीकरण और उप-टाइपिंग की उपयोगिता पर विश्वास करने की कम संभावना है क्योंकि वे [[ समुच्चय सिद्धान्त |सेट सिद्धान्त]] -आधारित टैक्सोनॉमी या वर्गीकरण प्रणालियों को अधिक शक्तिशाली और लचीला रूप में देखते हैं | पेड़ों की तुलना में.ओओ समर्थकों का कहना है कि इनहेरिटेंस/सबटाइपिंग मॉडल को पेड़ों तक सीमित करने की आवश्यकता नहीं है (हालांकि [[जावा (भाषा)]] जैसी कई लोकप्रिय ओओ भाषाओं में यह सीमा है), लेकिन गैर-ट्री ओओ समाधानों को सेट कीआधारित में तैयार करना अधिक कठिन माना जाता है। विषय-वस्तु पर आधारित विविधता प्रबंधन तकनीकों को रिलेशनल द्वारा प्राथमिकता दी जाती है। कम से कम, वे आमतौर पर संबंधपरक बीजगणित में उपयोग की जाने वाली तकनीकों से भिन्न हैं। | ||
* संरचना बनाम व्यवहार | *संरचना बनाम व्यवहार - OO मुख्य रूप से यह सुनिश्चित करने पर ध्यान केंद्रित करता है कि कार्यक्रम की संरचना उचित (रखरखाव योग्य, समझने योग्य, विस्तार योग्य, पुन: प्रयोज्य, सुरक्षित) है, जबकि संबंधपरक प्रणालियाँ इस बात पर ध्यान केंद्रित करती हैं कि परिणामी रन-टाइम सिस्टम में किस प्रकार का व्यवहार है (दक्षता, अनुकूलनशीलता) , दोष-सहिष्णुता, जीवंतता, तार्किक अखंडता, आदि)। ऑब्जेक्ट-ओरिएंटेड विधियाँ आम तौर पर मानती हैं कि ऑब्जेक्ट-ओरिएंटेड कोड और उसके इंटरफेस के प्राथमिक उपयोगकर्ता एप्लिकेशन डेवलपर हैं। संबंधपरक प्रणालियों में, सिस्टम के व्यवहार के बारे में अंतिम-उपयोगकर्ताओं के दृष्टिकोण को कभी-कभी अधिक महत्वपूर्ण माना जाता है। हालाँकि, संबंधपरक प्रश्न और "विचार" एप्लिकेशन- या कार्य-विशिष्ट कॉन्फ़िगरेशन में जानकारी प्रस्तुत करने की सामान्य तकनीक हैं। इसके अलावा, रिलेशनल स्थानीय या एप्लिकेशन-विशिष्ट संरचनाओं या तालिकाओं को बनाने से प्रतिबंधित नहीं करता है, हालांकि कई सामान्य विकास उपकरण सीधे ऐसी सुविधा प्रदान नहीं करते हैं, यह मानते हुए कि वस्तुओं का उपयोग इसके बजाय किया जाएगा। इससे यह जानना मुश्किल हो जाता है कि रिलेशनल का बताया गया गैर-डेवलपर परिप्रेक्ष्य रिलेशनल में अंतर्निहित है, या केवल वर्तमान अभ्यास और उपकरण कार्यान्वयन मान्यताओं का उत्पाद है। | ||
* सेट बनाम ग्राफ़ संबंध{{snd}} विभिन्न वस्तुओं (वस्तुओं या रिकॉर्ड) के बीच संबंध को प्रतिमानों के बीच अलग-अलग तरीके से | * सेट बनाम ग्राफ़ संबंध{{snd}} विभिन्न वस्तुओं (वस्तुओं या रिकॉर्ड) के बीच संबंध को प्रतिमानों के बीच अलग-अलग तरीके से नियंत्रित किया जाता है। संबंधपरक संबंध आमतौर पर सेट सिद्धांत से लिए गए मुहावरों पर आधारित होते हैं, जबकि वस्तु संबंध [[ग्राफ सिद्धांत]] (ट्री (ग्राफ सिद्धांत) सहित) से अपनाए गए मुहावरों की ओर झुकते हैं। हालाँकि प्रत्येक व्यक्ति दूसरे के समान ही जानकारी का प्रतिनिधित्व कर सकता है, लेकिन जानकारी तक पहुँचने और उसे प्रबंधित करने के लिए उनके द्वारा प्रदान किए जाने वाले दृष्टिकोण भिन्न-भिन्न होते हैं। | ||
वस्तु-संबंधपरक प्रतिबाधा बेमेल के परिणामस्वरूप, बहस के दोनों पक्षों के पक्षकारों द्वारा अक्सर यह तर्क दिया जाता है कि अन्य तकनीक को छोड़ दिया जाना चाहिए या उसका दायरा कम कर दिया जाना चाहिए।<ref name="RDMDBobjectmis">{{cite web| first = Ted| last=Neward | title = कंप्यूटर विज्ञान का वियतनाम| date=2006-06-26|access-date=2010-06-02| publisher = Interoperability Happens| url=https://www.odbms.org/wp-content/uploads/2013/11/031.01-Neward-The-Vietnam-of-Computer-Science-June-2006.pdf}}</ref> कुछ डेटाबेस समर्थक पारंपरिक प्रक्रियात्मक भाषाओं को कई OO भाषाओं की तुलना में RDBMS के साथ अधिक संगत मानते हैं; या सुझाव दें कि कम OO शैली का उपयोग किया जाना चाहिए। (विशेष रूप से, यह तर्क दिया जाता है कि एप्लिकेशन कोड में लंबे समय तक रहने वाले डोमेन ऑब्जेक्ट मौजूद नहीं होने चाहिए; ऐसी कोई भी ऑब्जेक्ट जो मौजूद है, उसे तब बनाया जाना चाहिए जब कोई क्वेरी की जाती है और लेनदेन या कार्य पूरा होने पर उसका निपटान किया जाना चाहिए)। इसके विपरीत, कुछ OO समर्थकों का तर्क है कि [[OODBMS]] जैसे अधिक OO-अनुकूल दृढ़ता तंत्र को विकसित और उपयोग किया जाना चाहिए, और संबंधपरक तकनीक को चरणबद्ध तरीके से समाप्त किया जाना चाहिए। कई (यदि अधिकतर नहीं) प्रोग्रामर और डीबीए इनमें से कोई भी दृष्टिकोण नहीं रखते हैं; और वस्तु-संबंधपरक प्रतिबाधा बेमेल को जीवन के मात्र तथ्य के रूप में देखें जिससे सूचना प्रौद्योगिकी को निपटना है। | |||
वस्तु-संबंधपरक प्रतिबाधा बेमेल के परिणामस्वरूप, बहस के दोनों पक्षों के पक्षकारों द्वारा अक्सर यह तर्क दिया जाता है कि अन्य तकनीक को छोड़ दिया जाना चाहिए या उसका दायरा कम कर दिया जाना चाहिए। <ref name="RDMDBobjectmis">{{cite web| first = Ted| last=Neward | title = कंप्यूटर विज्ञान का वियतनाम| date=2006-06-26|access-date=2010-06-02| publisher = Interoperability Happens| url=https://www.odbms.org/wp-content/uploads/2013/11/031.01-Neward-The-Vietnam-of-Computer-Science-June-2006.pdf}}</ref> कुछ डेटाबेस समर्थक पारंपरिक "प्रक्रियात्मक" भाषाओं को कई OO भाषाओं की तुलना में RDBMS के साथ अधिक संगत मानते हैं; या सुझाव दें कि कम OO शैली का उपयोग किया जाना चाहिए। (विशेष रूप से, यह तर्क दिया जाता है कि एप्लिकेशन कोड में लंबे समय तक रहने वाले डोमेन ऑब्जेक्ट मौजूद नहीं होने चाहिए; ऐसी कोई भी ऑब्जेक्ट जो मौजूद है, उसे तब बनाया जाना चाहिए जब कोई क्वेरी की जाती है और लेनदेन या कार्य पूरा होने पर उसका '''निपटान''' किया जाना चाहिए)। इसके विपरीत, कुछ OO समर्थकों का तर्क है कि [[OODBMS]] जैसे अधिक OO-अनुकूल दृढ़ता तंत्र को विकसित और उपयोग किया जाना चाहिए, और संबंधपरक तकनीक को चरणबद्ध तरीके से समाप्त किया जाना चाहिए। कई (यदि अधिकतर नहीं) प्रोग्रामर और डीबीए इनमें से कोई भी दृष्टिकोण नहीं रखते हैं; और वस्तु-संबंधपरक प्रतिबाधा बेमेल को जीवन के मात्र तथ्य के रूप में देखें जिससे सूचना प्रौद्योगिकी को निपटना है। | |||
यह भी तर्क दिया जाता है कि ओ/आर मैपिंग से कुछ स्थितियों में फायदा हो रहा है, लेकिन संभवत: इसकी अधिक बिक्री हो रही है: इसमें कमियों के अलावा फायदे भी हैं। संशयवादियों का कहना है कि इसका उपयोग करने से पहले सावधानी से सोचना उचित है, क्योंकि कुछ मामलों में इसका मूल्य थोड़ा बढ़ जाएगा।<ref>{{cite book|title=J2EE Design and Development|url=https://archive.org/details/expertoneononej200rodj|url-access=registration|first=Rod|last=Johnson|publisher=Wrox Press|date=2002|page=[https://archive.org/details/expertoneononej200rodj/page/256 256]|isbn=9781861007841 }}</ref> | यह भी तर्क दिया जाता है कि ओ/आर मैपिंग से कुछ स्थितियों में फायदा हो रहा है, लेकिन संभवत: इसकी अधिक बिक्री हो रही है: इसमें कमियों के अलावा फायदे भी हैं। संशयवादियों का कहना है कि इसका उपयोग करने से पहले सावधानी से सोचना उचित है, क्योंकि कुछ मामलों में इसका मूल्य थोड़ा बढ़ जाएगा।<ref>{{cite book|title=J2EE Design and Development|url=https://archive.org/details/expertoneononej200rodj|url-access=registration|first=Rod|last=Johnson|publisher=Wrox Press|date=2002|page=[https://archive.org/details/expertoneononej200rodj/page/256 256]|isbn=9781861007841 }}</ref> | ||
== यह भी देखें == | == यह भी देखें == | ||
* {{annotated link| | * {{annotated link|ऑब्जेक्ट-रिलेशनल मैपिंग }} | ||
* {{annotated link| | * {{annotated link|ऑब्जेक्ट-रिलेशनल डेटाबेस}} - डेटाबेस प्रबंधन प्रणाली | ||
== संदर्भ == | == संदर्भ == | ||
Revision as of 09:14, 16 July 2023
वस्तु-संबंधपरक प्रतिबाधा बेमेल वैचारिक और तकनीकी कठिनाइयों का सेट है जो अक्सर तब सामने आती है जब संगठन रिलेशनल डेटा स्टोर्स ( संबंधपरक डेटाबेस प्रबंधन प्रणाली [“आरडीबीएमएस”]) में डेटा संग्रहीत करते हैं और फिर डोमेन-संचालित ऑब्जेक्ट मॉडल के माध्यम से इस डेटा का उपयोग करते हैं, ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग भाषाओं में व्यवसाय-केंद्रित वस्तुओं को लागू करने की डिफ़ॉल्ट विधि। समस्याएँ डेटा को रिलेशनल या डोमेन ऑब्जेक्ट के रूप में संबोधित करने में विफलता से उत्पन्न नहीं होती हैं, बल्कि दो वैचारिक रूप से भिन्न तर्क मॉडल के डेटा मानों के बीच डेटा मैपिंग को लागू करने की कठिनाई के परिणामस्वरूप उत्पन्न होती हैं; दोनों मॉडल तार्किक मॉडल हैं जिन्हें उपयोग की गई तकनीक (डेटाबेस सर्वर, प्रोग्रामिंग भाषा, डिज़ाइन पैटर्न इत्यादि) के आधार पर अलग-अलग तरीके से लागू किया जा सकता है। ये मुद्दे केवल अनुप्रयोगों तक ही सीमित नहीं हैं, बल्कि उद्यम में मौजूद हैं, जब भी डेटा को रिलेशनल तरीके से संग्रहीत किया जाता है तो डोमेन-संचालित ऑब्जेक्ट मॉडल के रूप में उपयोग किया जाता है, और इसके विपरीत। इन कठिनाइयों को कभी-कभी ऑब्जेक्ट-ओरिएंटेड डेटा स्टोर के उपयोग से कम किया जाता है, लेकिन इसकी भी कार्यान्वयन कठिनाइयों का अपना सेट होता है।
वस्तु-संबंधपरक प्रतिबाधा बेमेल शब्द विद्युत अभियन्त्रण शब्द प्रतिबाधा मिलान से लिया गया है।
बेमेल
वस्तुएं (उदाहरण) दूसरे को संदर्भित करती हैं और इसलिए गणितीय अर्थ में निर्देशित ग्राफ बनाती हैं (लूप और चक्र सहित नेटवर्क)। इसके विपरीत, संबंधपरक स्कीमा सारणीबद्ध होती हैं और संबंधपरक बीजगणित पर आधारित होती हैं, जो जुड़े हुए विषम टुपल्स (प्रत्येक क्षेत्र के लिए अलग-अलग प्रकारों के साथ डेटा फ़ील्ड को "पंक्ति" में समूहित करना) को परिभाषित करती हैं, जहां लिंक हमेशा प्रतिवर्ती होते हैं (विदेशी कुंजी को पीछे की ओर ले जाया जा सकता है, चूँकि INNER JOIN सममित है), जो अप्रत्यक्ष ग्राफ़ के समान विशेषता है।
वस्तु-उन्मुख अवधारणाएँ
एनकैप्सुलेशन
ऑब्जेक्ट-ओरिएंटेड प्रोग्राम ऐसी तकनीकों के साथ डिज़ाइन किए गए हैं जिनके परिणामस्वरूप एनकैप्सुलेशन (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) ऑब्जेक्ट होते हैं जिनका आंतरिक प्रतिनिधित्व छिपाया जा सकता है। ऑब्जेक्ट-ओरिएंटेड फ्रेमवर्क में, किसी दिए गए ऑब्जेक्ट के अंतर्निहित गुणों को ऑब्जेक्ट के साथ लागू इंटरफ़ेस के बाहर किसी भी इंटरफ़ेस के संपर्क में नहीं आने की उम्मीद की जाती है। हालाँकि, अधिकांश ऑब्जेक्ट-रिलेशनल मैपिंग दृष्टिकोण किसी ऑब्जेक्ट की अंतर्निहित सामग्री को इंटरफ़ेस के साथ इंटरैक्ट करने के लिए उजागर करते हैं जिसे ऑब्जेक्ट कार्यान्वयन निर्दिष्ट नहीं कर सकता है। इसलिए, यह ऑब्जेक्ट-रिलेशनल मैपिंग ऑब्जेक्ट के एनकैप्सुलेशन का उल्लंघन करती है, क्योंकि कई ऑब्जेक्ट-रिलेशनल मैपर स्वचालित रूप से डेटाबेस कॉलम के अनुरूप सार्वजनिक फ़ील्ड उत्पन्न करते हैं। कुछ फ्रेमवर्क इसके बजाय मेटाप्रोग्रामिंग तकनीकों का उपयोग करते हैं, इस प्रकार इनकैप्सुलेशन का उल्लंघन करने से बचते हैं।
अभिगम्यता
संबंधपरक सोच में, निजी बनाम सार्वजनिक पहुंच आवश्यकता के सापेक्ष है। ऑब्जेक्ट-ओरिएंटेड (OO) मॉडल में यह डेटा की स्थिति की पूर्ण विशेषता है। संबंधपरक और OO मॉडल में अक्सर सापेक्षता बनाम वर्गीकरण और विशेषताओं की निरपेक्षता पर टकराव होता है।
इंटरफ़ेस, वर्ग, वंशानुक्रम और बहुरूपता
ऑब्जेक्ट-ओरिएंटेड प्रतिमान के तहत, ऑब्जेक्ट में इंटरफ़ेस (कंप्यूटर विज्ञान) होते हैं जो साथ उस ऑब्जेक्ट के आंतरिक तक मात्र पहुंच प्रदान करते हैं। दूसरी ओर, संबंधपरक मॉडल अखंडता सुनिश्चित करने के लिए अलग-अलग दृष्टिकोण और बाधाएं प्रदान करने के लिए व्युत्पन्न संबंध चर देखें (डेटाबेस) (विचार) का उपयोग करता है। इसी प्रकार, वस्तुओं के वर्गों, वंशानुक्रम (कंप्यूटर विज्ञान) और बहुरूपता (कंप्यूटर विज्ञान) के लिए आवश्यक ओओपी अवधारणाएँ, रिलेशनल डेटाबेस सिस्टम द्वारा समर्थित नहीं हैं।
संबंधपरक अवधारणाओं का मानचित्रण
संबंधपरक अवधारणाओं और वस्तु-उन्मुख अवधारणाओं के बीच उचित मानचित्रण बनाया जा सकता है यदि संबंधपरक डेटाबेस तालिकाओं को वस्तु-उन्मुख विश्लेषण में पाए जाने वाले संघों (वस्तु-उन्मुख प्रोग्रामिंग) से जोड़ा जाता है [आगे स्पष्टीकरण की आवश्यकता है]।
डेटा प्रकार अंतर
मौजूदा रिलेशनल और OO भाषाओं के बीच बड़ा बेमेल प्रकार सिस्टम अंतर है। संबंधपरक मॉडल सख्ती से उप-संदर्भ विशेषताओं (या सूचक (कंप्यूटर प्रोग्रामिंग)) को प्रतिबंधित करता है, जबकि ओओ भाषाएं उप-संदर्भ व्यवहार को अपनाती हैं और उसकी अपेक्षा करती हैं। अदिश (कंप्यूटिंग) प्रकार और उनके ऑपरेटर शब्दार्थ मॉडल के बीच काफी भिन्न हो सकते हैं, जिससे मैपिंग में समस्याएं पैदा हो सकती हैं।
उदाहरण के लिए, अधिकांश एसक्यूएल सिस्टम अलग-अलग संयोजनों और सीमित अधिकतम लंबाई के साथ स्ट्रिंग (कंप्यूटर विज्ञान) प्रकारों का समर्थन करते हैं (ओपन-एंडेड टेक्स्ट प्रकार प्रदर्शन में बाधा डालते हैं), जबकि अधिकांश ओओ भाषाएं संयोजन को केवल सॉर्ट एल्गोरिथ्म करने के लिए तर्क के रूप में मानती हैं और स्ट्रिंग्स आंतरिक रूप से उपलब्ध मेमोरी के आकार की होती हैं। अधिक सूक्ष्म, लेकिन संबंधित उदाहरण यह है कि एसक्यूएल सिस्टम अक्सर तुलना के प्रयोजनों के लिए स्ट्रिंग में पिछली व्हाइटस्पेस (कंप्यूटर विज्ञान) को अनदेखा कर देते हैं, जबकि OO स्ट्रिंग लाइब्रेरीज़ ऐसा नहीं करते हैं। ओओ भाषा में अन्य आदिम प्रकारों के संभावित मूल्यों को सीमित करने के मामले में नए डेटा प्रकारों का निर्माण करना आम तौर पर संभव नहीं है।
संरचनात्मक और अखंडता अंतर
एक और बेमेल का संबंध विपरीत मॉडलों के संरचनात्मक और अखंडता पहलुओं में अंतर से है। ओओ भाषाओं में, वस्तुओं को अन्य वस्तुओं से बनाया जा सकता है - अक्सर उच्च स्तर तक - या अधिक सामान्य परिभाषा से विशेषज्ञ। इससे रिलेशनल स्कीमों की मैपिंग कम सरल हो सकती है। ऐसा इसलिए है क्योंकि रिलेशनल डेटा को वैश्विक, अननेस्टेड रिलेशन वेरिएबल्स के नामित सेट में दर्शाया जाता है। स्वयं संबंध, ही हेडर के अनुरूप टुपल्स के सेट होने के कारण (टपल रिलेशनल कैलकुलस देखें) ओओ भाषाओं में कोई आदर्श समकक्ष नहीं है। ओओ भाषाओं में बाधाओं को आम तौर पर इस तरह घोषित नहीं किया जाता है, लेकिन एन्कैप्सुलेटेड आंतरिक डेटा पर काम करने वाले कोड के आसपास सुरक्षा तर्क बढ़ाने वाले अपवाद के रूप में प्रकट होते हैं। दूसरी ओर, रिलेशनल मॉडल, स्केलर प्रकार, विशेषताओं, संबंध चर और संपूर्ण डेटाबेस पर घोषणात्मक प्रोग्रामिंग बाधाओं की मांग करता है।
जोड़ तोड़ मतभेद
हालाँकि, अर्थ संबंधी अंतर विशेष रूप से विपरीत मॉडलों के हेरफेर पहलुओं में स्पष्ट हैं। रिलेशनल मॉडल में क्वेरी और डेटा के हेरफेर में उपयोग के लिए आदिम ऑपरेटरों का आंतरिक, अपेक्षाकृत छोटा और अच्छी तरह से परिभाषित सेट होता है, जबकि ओओ भाषाएं आम तौर पर कस्टम-निर्मित या निचले स्तर, केस- और भौतिक-पहुंच के माध्यम से क्वेरी और हेरफेर को संभालती हैं। -पथ-विशिष्ट अनिवार्य प्रोग्रामिंग संचालन। कुछ OO भाषाओं में घोषणात्मक क्वेरी उपभाषाओं के लिए समर्थन होता है, लेकिन क्योंकि OO भाषाएँ आम तौर पर सूचियों और शायद हैश तालिकाओ से निपटती हैं, इसलिए जोड़-तोड़ करने वाले आदिम आवश्यक रूप से संबंधपरक मॉडल के सेट (कंप्यूटर विज्ञान)-आधारित संचालन से अलग होते हैं।
लेन-देन संबंधी मतभेद
समवर्ती और लेन-देन के पहलू भी काफी भिन्न हैं। विशेष रूप से,डेटाबेस लेनदेन, डेटाबेस द्वारा किए गए कार्य की सबसे छोटी इकाई, ओओ भाषाओं में कक्षाओं द्वारा किए गए किसी भी ऑपरेशन की तुलना में संबंधपरक डेटाबेस में बहुत बड़ी होती है। रिलेशनल डेटाबेस में लेनदेन मनमाने ढंग से डेटा हेरफेर के गतिशील रूप से बंधे हुए सेट होते हैं, जबकि ओओ भाषा में लेनदेन की ग्रैन्युलैरिटी आम तौर पर आदिम-टाइप किए गए फ़ील्ड के लिए व्यक्तिगत असाइनमेंट के स्तर पर होती है। सामान्य तौर पर, OO भाषाओं में अलगाव या स्थायित्व का कोई एनालॉग नहीं होता है, इसलिए परमाणुता और स्थिरता केवल उन आदिम प्रकारों के क्षेत्रों में लिखते समय सुनिश्चित की जाती है।
प्रतिबाधा बेमेल को हल करना
ऑब्जेक्ट-ओरिएंटेड प्रोग्रामों के लिए प्रतिबाधा बेमेल समस्या के आसपास काम करना नियोजित किए जा रहे विशिष्ट तर्क प्रणालियों में अंतर की पहचान के साथ शुरू होता है। फिर बेमेल को या तो कम कर दिया जाता है या उसकी भरपाई कर दी जाती है।[1]
वैकल्पिक आर्किटेक्चर
ऑब्जेक्ट-रिलेशनल प्रतिबाधा बेमेल समस्या OO और डेटाबेस के बीच सार्वभौमिक समस्या नहीं है। जैसा कि नाम से पता चलता है, यह प्रतिबाधा समस्या केवल संबंधपरक डेटाबेस के साथ होती है। इस समस्या का सबसे आम समाधान वैकल्पिक डेटाबेस, जैसे NoSQL या XML डेटाबेस का उपयोग करना है।
न्यूनीकरण
ऑब्जेक्ट ओरिएंटेड डेटाबेस मैनेजमेंट सिस्टम (ओओडीबीएमएस) बनाने के कुछ प्रयास किए गए हैं जो प्रतिबाधा बेमेल समस्या से बचेंगे। हालाँकि, वे संबंधपरक डेटाबेस की तुलना में व्यवहार में कम सफल रहे हैं, आंशिक रूप से डेटा मॉडल के आधार के रूप में OO सिद्धांतों की सीमाओं के कारण। [2] सॉफ़्टवेयर ट्रांसेक्शनल मेमोरीजैसी धारणाओं के माध्यम से ओओ भाषाओं की डेटाबेस जैसी क्षमताओं को विस्तारित करने पर शोध किया गया है।
प्रतिबाधा बेमेल समस्या का सामान्य समाधान डोमेन और फ्रेमवर्क तर्क को परत करना है। इस योजना में, OO भाषा का उपयोग अधिक स्थिर मानचित्रण के प्रयास के बजाय रनटाइम पर कुछ संबंधपरक पहलुओं को मॉडल करने के लिए किया जाता है। इस विधि को नियोजित करने वाले फ़्रेमवर्क में आम तौर पर टुपल के लिए एनालॉग होगा, आमतौर पर "डेटासेट" घटक में "पंक्ति" के रूप में या सामान्य "इकाई उदाहरण" वर्ग के रूप में, साथ ही किसी संबंध के लिए एनालॉग भी होगा। इस दृष्टिकोण के लाभों में शामिल हो सकते हैं:
- डोमेन डेटा के परिवहन, प्रस्तुति और सत्यापन के आसपास ढांचे और स्वचालन के निर्माण के लिए सीधे रास्ते होते हैं ।
- छोटा कोड आकार; तेज़ संकलन और लोड समय।
- डेटाबेस स्कीमा को गतिशील रूप से बदलने की क्षमता।
- नाम-स्थान और अर्थ संबंधी बेमेल मुद्दों से बचा जाता है।
- अभिव्यंजक बाधा जाँच
- कोई जटिल मानचित्रण आवश्यक नहीं
नुकसान में शामिल हो सकते हैं:
- स्थैतिक प्रकार की "सुरक्षा" जांच का अभाव। टाइप किए गए ्सेसर्स का उपयोग कभी-कभी इसे कम करने के तरीके के रूप में किया जाता है।
- रनटाइम निर्माण और पहुंच की संभावित प्रदर्शन लागत।
- ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में बहुरूपता जैसे विशिष्ट OO पहलुओं का मूल रूप से उपयोग करने में असमर्थता होती हैं।
मुआवजा
ओओ एप्लिकेशन कोड के भीतर प्रवचन के स्तरो का मिश्रण समस्याएं प्रस्तुत करता है, लेकिन क्षतिपूर्ति के लिए कुछ सामान्य तंत्रों का उपयोग किया जाता है। सबसे बड़ी चुनौती चर्चा के उस स्तर के भीतर फ्रेमवर्क समर्थन, डेटा हेरफेर और प्रस्तुति पैटर्न का स्वचालन प्रदान करना है जिसमें डोमेन डेटा को मॉडल किया जा रहा है। इसे संबोधित करने के लिए, प्रतिबिंब और/या स्वचालित प्रोग्रामिंग का उपयोग किया जाता है। प्रतिबिंब कोड (वर्गों) को डेटा के रूप में संबोधित करने की अनुमति देता है और इस प्रकार डेटा के परिवहन, प्रस्तुति, अखंडता आदि का स्वचालन प्रदान करता है। जनरेशन इकाई संरचनाओं को कोड जनरेशन टूल या मेटा-प्रोग्रामिंग भाषाओं के लिए डेटा इनपुट के रूप में संबोधित करके समस्या का समाधान करता है, जो सामूहिक रूप से कक्षाओं और सहायक बुनियादी ढांचे का निर्माण करते हैं। ये दोनों योजनाएँ अभी भी कुछ विसंगतियों के अधीन हो सकती हैं जहाँ चर्चा के ये स्तर विलीन हो जाते हैं। उदाहरण के लिए, जेनरेट की गई इकाई कक्षाओं में आम तौर पर ऐसे गुण होंगे जो डोमेन पर मैप होते हैं (उदाहरण के लिए नाम, पता) और साथ ही ऐसे गुण जो राज्य प्रबंधन और अन्य ढांचे के बुनियादी ढांचे (उदाहरण के लिए IsModified) प्रदान करते हैं।
घटना
यद्यपि ऑब्जेक्ट-रिलेशनल प्रतिबाधा बेमेल सामान्य रूप से ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के साथ हो सकता है, कठिनाई का विशेष क्षेत्र ऑब्जेक्ट रिलेशनल मैपर्स (ओआरएम) के साथ है।[3] चूँकि ओएमआर को अक्सर कॉन्फ़िगरेशन, एनोटेशन और प्रतिबंधित डोमेन-विशिष्ट भाषाओं के संदर्भ में निर्दिष्ट किया जाता है, इसलिए इसमें प्रतिबाधा बेमेल को हल करने के लिए पूर्ण प्रोग्रामिंग भाषा के लचीलेपन का अभाव होता है।
विवाद
सच्चा आरडीबीएमएस मॉडल
क्रिस्टोफर जे. डेट और अन्य लोगों द्वारा यह तर्क दिया गया है कि वास्तव में संबंधपरक डीबीएमएस ऐसी कोई समस्या उत्पन्न नहीं करेगा,[4][5][6] चूँकि डेटा डोमेन और क्लास (कंप्यूटर विज्ञान) अनिवार्य रूप से ही चीज़ हैं। कक्षाओं और संबंधपरक स्कीमाटा के बीच मूल मानचित्रण मौलिक डिजाइन गलती है;[7] और डेटाबेस तालिका (संबंध) के भीतर व्यक्तिगत टुपल्स को संस्थाओं के बीच संबंध स्थापित करने के रूप में देखा जाना चाहिए; स्वयं जटिल संस्थाओं के प्रतिनिधित्व के रूप में नहीं। हालाँकि, यह दृश्य ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के प्रभाव और भूमिका को कम कर देता है, इसे फ़ील्ड प्रकार प्रबंधन प्रणाली से थोड़ा अधिक उपयोग करता है।
बाधाएं और अवैध लेनदेन
प्रतिबाधा बेमेल डोमेन ऑब्जेक्ट और उपयोगकर्ता इंटरफ़ेस के बीच प्रोग्रामिंग में है। ऑपरेटरों, प्रबंधकों और अन्य गैर-प्रोग्रामरों को डेटाबेस में रिकॉर्ड तक पहुंचने और हेरफेर करने की अनुमति देने के लिए परिष्कृत उपयोगकर्ता इंटरफ़ेस के लिए अक्सर विभिन्न डेटाबेस विशेषताओं (नाम और प्रकार से परे) की प्रकृति के बारे में गहन ज्ञान की आवश्यकता होती है। विशेष रूप से, उपयोगकर्ता इंटरफ़ेस को डिज़ाइन करना अच्छा अभ्यास माना जाता है (अंतिम-उपयोगकर्ता उत्पादकता के दृष्टिकोण से) ताकि यूआई अवैध लेनदेन (जो डेटाबेस बाधा का उल्लंघन करते हैं) को प्रवेश करने से रोक सके; ऐसा करने के लिए कोड दोहराव रिलेशनल स्कीमाटा में मौजूद अधिकांश तर्क को कोड में डुप्लिकेट करने की आवश्यकता होती है।
कुछ कोड-विकास ढाँचे डेटाबेस के स्कीमा (जैसे संदर्भात्मक अखंडता बाधाएं) में दर्शाए गए तर्क के कुछ रूपों का लाभ उठा सकते हैं, ताकि ऐसे मुद्दों को किसी मामले पर लिखे गए तदर्थ कोड के बजाय लाइब्रेरी रूटीन के माध्यम से सामान्य और मानक फैशन में नियंत्रितजा सके। -मामला-दर-मामला आधार।
SQL-विशिष्ट प्रतिबाधा और समाधान
यह तर्क दिया गया है कि SQL, डोमेन प्रकारों के बहुत सीमित सेट (और अन्य कथित त्रुटियों) के कारण उचित ऑब्जेक्ट और डोमेन-मॉडलिंग को कठिन बना देता है; और यह कि SQL DBMS और एप्लिकेशन प्रोग्राम (चाहे ऑब्जेक्ट-ओरिएंटेड शैली में लिखा गया हो या नहीं) के बीच बहुत ही हानिपूर्ण और अकुशल इंटरफ़ेस बनाता है। हालाँकि, SQL वर्तमान में बाज़ार में मात्र व्यापक रूप से स्वीकृत सामान्य डेटाबेस भाषा है; विक्रेता-विशिष्ट क्वेरी भाषाओं का उपयोग टाले जाने योग्य होने पर खराब अभ्यास के रूप में देखा जाता है। अन्य डेटाबेस भाषाएँ जैसे बिजनेस सिस्टम 12 और ट्यूटोरियल डी प्रस्तावित की गई हैं; लेकिन इनमें से किसी को भी डीबीएमएस विक्रेताओं द्वारा व्यापक रूप से नहीं अपनाया गया है।
Oracle और Microsoft SQL सर्वर जैसे मुख्यधारा ऑब्जेक्ट-रिलेशनल DBMS के वर्तमान संस्करणों में, उपरोक्त बिंदु गैर-मुद्दा हो सकता है। इन इंजनों के साथ, किसी दिए गए डेटाबेस की कार्यक्षमता को आधुनिक OO भाषा (Oracle के लिए Java, और SQL सर्वर के लिए Microsoft .NET भाषा) में लिखे गए संग्रहीत कोड (फ़ंक्शन और प्रक्रियाओं) के माध्यम से मनमाने ढंग से बढ़ाया जा सकता है, और इन कार्यों को लागू किया जा सकता है SQL कथनों को पारदर्शी तरीके से इन-टर्न करें: अर्थात, उपयोगकर्ता को न तो पता है और न ही इसकी परवाह है कि ये फ़ंक्शन/प्रक्रियाएँ मूल रूप से डेटाबेस इंजन का हिस्सा नहीं थीं। आधुनिक सॉफ्टवेयर-विकास प्रतिमान पूरी तरह से समर्थित हैं: इस प्रकार, कोई लाइब्रेरी रूटीन का सेट बना सकता है जिसे कई डेटाबेस स्कीमा में पुन: उपयोग किया जा सकता है
इन विक्रेताओं ने DBMS बैक-एंड पर OO-भाषा एकीकरण का समर्थन करने का निर्णय लिया क्योंकि उन्हें एहसास हुआ कि, SQL में प्रक्रियात्मक निर्माणों को जोड़ने के लिए ISO SQL-99 समिति के प्रयासों के बावजूद, SQL में पुस्तकालयों और डेटा संरचनाओं का समृद्ध सेट कभी नहीं होगा। आज के एप्लिकेशन प्रोग्रामर इसे हल्के में लेते हैं, और मुख्य SQL भाषा का विस्तार करने का प्रयास करने के बजाय इनका यथासंभव सीधे लाभ उठाना उचित है। नतीजतन, "एप्लिकेशन प्रोग्रामिंग" और "डेटाबेस प्रशासन" के बीच का अंतर अब धुंधला हो गया है: बाधाओं और ट्रिगर्स जैसी सुविधाओं के मजबूत कार्यान्वयन के लिए अक्सर दोहरे डीबीए/ओओ-प्रोग्रामिंग कौशल वाले व्यक्ति या इन कौशलों को संयोजित करने वाले व्यक्तियों के बीच साझेदारी की आवश्यकता हो सकती है। . यह तथ्य नीचे दिए गए "जिम्मेदारी के विभाजन" मुद्दे पर भी लागू होता है।
हालाँकि, कुछ लोग यह कहेंगे कि यह विवाद इस तथ्य के कारण विवादास्पद है कि: (1) आरडीबीएमएस का उद्देश्य कभी भी ऑब्जेक्ट मॉडलिंग की सुविधा प्रदान करना नहीं था, और (2) एसक्यूएल को आम तौर पर केवल हानिपूर्ण या अक्षम इंटरफ़ेस भाषा के रूप में देखा जाना चाहिए जब कोई हो ऐसा समाधान प्राप्त करने का प्रयास किया जा रहा है जिसके लिए RDBMSes डिज़ाइन नहीं किए गए थे। SQL वह काम करने में बहुत कुशल है जिसके लिए इसे डिज़ाइन किया गया था, अर्थात् डेटा के बड़े सेट को क्वेरी करना, सॉर्ट करना, फ़िल्टर करना और संग्रहीत करना। कुछ लोग अतिरिक्त रूप से इंगित करेंगे कि बैक-एंड में ओओ भाषा कार्यक्षमता को शामिल करने से खराब वास्तुशिल्प अभ्यास की सुविधा मिलती है, क्योंकि यह आरडीबीएमएस के विपरीत, डेटा स्तर में उच्च स्तरीय एप्लिकेशन तर्क को स्वीकार करता है।
डेटा की कैनोनिकल प्रतिलिपि का स्थान
यहां राज्य की विहित प्रति स्थित है। डेटाबेस मॉडल आम तौर पर मानता है कि डेटाबेस प्रबंधन प्रणाली उद्यम से संबंधित राज्य का मात्र आधिकारिक भंडार है; किसी एप्लिकेशन प्रोग्राम द्वारा रखी गई ऐसी स्थिति की कोई भी प्रतिलिपि बस यही है – अस्थायी प्रतियां (जो पुरानी हो सकती हैं, यदि अंतर्निहित डेटाबेस रिकॉर्ड को बाद में किसी लेनदेन द्वारा संशोधित किया गया हो)। कई ऑब्जेक्ट-ओरिएंटेड प्रोग्रामर ऑब्जेक्ट के इन-मेमोरी अभ्यावेदन को कैनोनिकल डेटा के रूप में देखना पसंद करते हैं, और डेटाबेस को बैकिंग स्टोर और दृढ़ता तंत्र के रूप में देखना पसंद करते हैं।
उत्तरदायित्व का विभाजन
विवाद का अन्य मुद्दा एप्लिकेशन प्रोग्रामर और डेटाबेस प्रशासक (डीबीए) के बीच जिम्मेदारी का उचित विभाजन है। अक्सर ऐसा होता है कि एप्लिकेशन कोड में आवश्यक बदलावों के लिए (अनुरोधित नई सुविधा या कार्यक्षमता को लागू करने के लिए) डेटाबेस परिभाषा में संबंधित बदलावों की आवश्यकता होती है; अधिकांश संगठनों में, डेटाबेस परिभाषा डीबीए की ज़िम्मेदारी है। उत्पादन डेटाबेस प्रणाली को 24 घंटे बनाए रखने की आवश्यकता के कारण कई डीबीए डेटाबेस स्कीमाटा में ऐसे बदलाव करने के लिए अनिच्छुक हैं जिन्हें वे अनावश्यक या अनावश्यक मानते हैं और कुछ मामलों में ऐसा करने से सीधे इनकार कर देते हैं। विकासात्मक डेटाबेस का उपयोग (उत्पादन प्रणालियों के अलावा) कुछ हद तक मदद कर सकता है; लेकिन जब नया विकसित एप्लिकेशन लाइव होगा तो डीबीए को किसी भी बदलाव को मंजूरी देने की आवश्यकता होगी। कुछ प्रोग्रामर इसे अकर्मण्यता के रूप में देखते हैं; हालाँकि, यदि डेटाबेस परिभाषा में कोई भी बदलाव उत्पादन प्रणाली में सेवा की हानि का कारण बनता है, तो डीबीए को अक्सर जिम्मेदार ठहराया जाता है - परिणामस्वरूप, कई डीबीए एप्लिकेशन कोड में डिज़ाइन परिवर्तन शामिल करना पसंद करते हैं, जहां डिज़ाइन दोषों के भयावह परिणाम होने की संभावना बहुत कम होती है।
हालांकि, डीबीए और डेवलपर्स के बीच गैर-अकार्यात्मक संबंध वाले संगठनों में, उपरोक्त मुद्दा खुद को प्रस्तुत नहीं करना चाहिए, क्योंकि डेटाबेस स्कीमा को बदलने या न करने का निर्णय केवल व्यावसायिक जरूरतों से प्रेरित होगा: अतिरिक्त डेटा को बनाए रखने के लिए नई आवश्यकता या ए उदाहरण के लिए, महत्वपूर्ण एप्लिकेशन के प्रदर्शन को बढ़ावा देने से स्कीमा संशोधन शुरू हो जाएगा।
दार्शनिक मतभेद
OO और संबंधपरक मॉडल के बीच प्रमुख दार्शनिक अंतरों को निम्नानुसार संक्षेपित किया जा सकता है |
- घोषणात्मक बनाम अनिवार्य इंटरफेस – संबंधपरक सोच डेटा को इंटरफ़ेस के रूप में उपयोग करती है, व्यवहार को इंटरफ़ेस के रूप में नहीं। इस प्रकार इसमें ओओ के व्यवहारिक झुकाव के विपरीत डिजाइन दर्शन में घोषणात्मक झुकाव है। (कुछ संबंधपरक प्रस्तावक जटिल व्यवहार प्रदान करने के लिए ट्रिगर्स, संग्रहीत प्रक्रियाओं आदि का उपयोग करने का सुझाव देते हैं, लेकिन यह सामान्य दृष्टिकोण नहीं है।)
- स्कीमा बाउंड - ऑब्जेक्ट को "पैरेंट स्कीमा" का पालन करने की आवश्यकता नहीं होती है जिसके लिए किसी ऑब्जेक्ट के गुण या एक्सेसर्स होते हैं, जबकि तालिका पंक्तियों को इकाई की स्कीमा का पालन करना होगा। दी गई पंक्ति और केवल इकाई से संबंधित होनी चाहिए। OO में निकटतम चीज़ वंशानुक्रम है, लेकिन यह आम तौर पर पेड़ के आकार का और वैकल्पिक है। गतिशील डेटाबेस प्रणालियाँ जो तदर्थ स्तंभों की अनुमति देती हैं, स्कीमा बाध्यता को शिथिल कर सकती हैं, लेकिन ऐसी प्रणालियाँ या तो वर्तमान में दुर्लभ हैं, या "संबंधपरक" के रूप में उनका वर्गीकरण प्रश्न में है।
- प्रवेश नियम – रिलेशनल डेटाबेस में, विशेषताओं को पूर्वनिर्धारित रिलेशनल ऑपरेटरों के माध्यम से एक्सेस और परिवर्तित किया जाता है, जबकि OO प्रत्येक वर्ग को अपना स्वयं का राज्य परिवर्तन इंटरफ़ेस और अभ्यास बनाने की अनुमति देता है। OO का स्व-संचालन संज्ञा दृष्टिकोण प्रत्येक वस्तु को स्वतंत्रता देता है जिसे संबंधपरक मॉडल अनुमति नहीं देता है। यह मानक बनाम स्थानीय स्वतंत्रता की बहस है। ओओ का तर्क है कि संबंधपरक मानक अभिव्यक्ति को सीमित करते हैं, जबकि संबंधपरक समर्थकों का सुझाव है कि नियम का पालन अधिक अमूर्त गणित जैसे तर्क, अखंडता और डिजाइन स्थिरता की अनुमति देता है।
- संज्ञा और क्रिया के बीच संबंध – OO क्रियाओं (क्रियाओं) और संज्ञाओं (संस्थाओं) के बीच मजबूत संबंध को प्रोत्साहित करता है, जिस पर परिचालन संचालित होता है। संज्ञा और क्रिया दोनों से युक्त परिणामी कसकर बंधी इकाई को आमतौर पर वर्ग (कंप्यूटर विज्ञान) कहा जाता है, या ओओ विश्लेषण में, संकल्पनात्मक मॉडल (कंप्यूटर विज्ञान) कहा जाता है। संबंधपरक डिज़ाइन आम तौर पर यह नहीं मानते हैं कि ऐसे तंग संघों (संबंधपरक ऑपरेटरों के बाहर) के बारे में कुछ भी प्राकृतिक या तार्किक है।
- वस्तु की पहचान – वस्तुओं (अपरिवर्तनीय को छोड़कर) को आम तौर पर विशिष्ट पहचान माना जाता है; दो वस्तुएँ जो निश्चित समय पर ही स्थिति में होती हैं, उन्हें समान नहीं माना जाता है। दूसरी ओर, संबंधों में इस प्रकार की पहचान की कोई अंतर्निहित अवधारणा नहीं होती है। जैसा कि कहा गया है, विश्व स्तर पर अद्वितीय उम्मीदवार कुंजी के उपयोग के माध्यम से डेटाबेस में रिकॉर्ड के लिए "पहचान" बनाना आम बात है; हालाँकि कई लोग इसे किसी भी डेटाबेस रिकॉर्ड के लिए ख़राब अभ्यास मानते हैं जिसका वास्तविक विश्व इकाई के साथ -से-एक पत्राचार नहीं होता है। (संबंध, वस्तुओं की तरह, पहचान उद्देश्यों के लिए बाहरी दुनिया में मौजूद होने पर डोमेन कुंजियों का उपयोग कर सकते हैं)। व्यवहार में संबंधपरक प्रणालियाँ स्थायी और निरीक्षण योग्य पहचान तकनीकों के लिए प्रयास करती हैं और उनका समर्थन करती हैं, जबकि वस्तु पहचान तकनीकें क्षणिक या स्थितिजन्य होती हैं।
- सामान्यीकरण – डेटाबेस सामान्यीकरण प्रथाओं को अक्सर OO डिज़ाइन द्वारा अनदेखा कर दिया जाता है। हालाँकि, यह OO की मूल विशेषता के बजाय केवल बुरी आदत हो सकती है। वैकल्पिक दृष्टिकोण यह है कि ऑब्जेक्ट का संग्रह, किसी प्रकार के पॉइंटर (कंप्यूटर प्रोग्रामिंग) के माध्यम से जुड़ा हुआ, नेटवर्क डेटाबेस के समान है; जिसे बदले में अत्यंत असामान्य संबंधपरक डेटाबेस के रूप में देखा जा सकता है।
- स्कीमा विरासत – अधिकांश रिलेशनल डेटाबेस स्कीमा इनहेरिटेंस का समर्थन नहीं करते हैं। यद्यपि इस तरह की सुविधा को ओओपी के साथ संघर्ष को कम करने के लिए सिद्धांत में जोड़ा जा सकता है, संबंधपरक समर्थकों को पदानुक्रमित वर्गीकरण और उप-टाइपिंग की उपयोगिता पर विश्वास करने की कम संभावना है क्योंकि वे सेट सिद्धान्त -आधारित टैक्सोनॉमी या वर्गीकरण प्रणालियों को अधिक शक्तिशाली और लचीला रूप में देखते हैं | पेड़ों की तुलना में.ओओ समर्थकों का कहना है कि इनहेरिटेंस/सबटाइपिंग मॉडल को पेड़ों तक सीमित करने की आवश्यकता नहीं है (हालांकि जावा (भाषा) जैसी कई लोकप्रिय ओओ भाषाओं में यह सीमा है), लेकिन गैर-ट्री ओओ समाधानों को सेट कीआधारित में तैयार करना अधिक कठिन माना जाता है। विषय-वस्तु पर आधारित विविधता प्रबंधन तकनीकों को रिलेशनल द्वारा प्राथमिकता दी जाती है। कम से कम, वे आमतौर पर संबंधपरक बीजगणित में उपयोग की जाने वाली तकनीकों से भिन्न हैं।
- संरचना बनाम व्यवहार - OO मुख्य रूप से यह सुनिश्चित करने पर ध्यान केंद्रित करता है कि कार्यक्रम की संरचना उचित (रखरखाव योग्य, समझने योग्य, विस्तार योग्य, पुन: प्रयोज्य, सुरक्षित) है, जबकि संबंधपरक प्रणालियाँ इस बात पर ध्यान केंद्रित करती हैं कि परिणामी रन-टाइम सिस्टम में किस प्रकार का व्यवहार है (दक्षता, अनुकूलनशीलता) , दोष-सहिष्णुता, जीवंतता, तार्किक अखंडता, आदि)। ऑब्जेक्ट-ओरिएंटेड विधियाँ आम तौर पर मानती हैं कि ऑब्जेक्ट-ओरिएंटेड कोड और उसके इंटरफेस के प्राथमिक उपयोगकर्ता एप्लिकेशन डेवलपर हैं। संबंधपरक प्रणालियों में, सिस्टम के व्यवहार के बारे में अंतिम-उपयोगकर्ताओं के दृष्टिकोण को कभी-कभी अधिक महत्वपूर्ण माना जाता है। हालाँकि, संबंधपरक प्रश्न और "विचार" एप्लिकेशन- या कार्य-विशिष्ट कॉन्फ़िगरेशन में जानकारी प्रस्तुत करने की सामान्य तकनीक हैं। इसके अलावा, रिलेशनल स्थानीय या एप्लिकेशन-विशिष्ट संरचनाओं या तालिकाओं को बनाने से प्रतिबंधित नहीं करता है, हालांकि कई सामान्य विकास उपकरण सीधे ऐसी सुविधा प्रदान नहीं करते हैं, यह मानते हुए कि वस्तुओं का उपयोग इसके बजाय किया जाएगा। इससे यह जानना मुश्किल हो जाता है कि रिलेशनल का बताया गया गैर-डेवलपर परिप्रेक्ष्य रिलेशनल में अंतर्निहित है, या केवल वर्तमान अभ्यास और उपकरण कार्यान्वयन मान्यताओं का उत्पाद है।
- सेट बनाम ग्राफ़ संबंध – विभिन्न वस्तुओं (वस्तुओं या रिकॉर्ड) के बीच संबंध को प्रतिमानों के बीच अलग-अलग तरीके से नियंत्रित किया जाता है। संबंधपरक संबंध आमतौर पर सेट सिद्धांत से लिए गए मुहावरों पर आधारित होते हैं, जबकि वस्तु संबंध ग्राफ सिद्धांत (ट्री (ग्राफ सिद्धांत) सहित) से अपनाए गए मुहावरों की ओर झुकते हैं। हालाँकि प्रत्येक व्यक्ति दूसरे के समान ही जानकारी का प्रतिनिधित्व कर सकता है, लेकिन जानकारी तक पहुँचने और उसे प्रबंधित करने के लिए उनके द्वारा प्रदान किए जाने वाले दृष्टिकोण भिन्न-भिन्न होते हैं।
वस्तु-संबंधपरक प्रतिबाधा बेमेल के परिणामस्वरूप, बहस के दोनों पक्षों के पक्षकारों द्वारा अक्सर यह तर्क दिया जाता है कि अन्य तकनीक को छोड़ दिया जाना चाहिए या उसका दायरा कम कर दिया जाना चाहिए। [8] कुछ डेटाबेस समर्थक पारंपरिक "प्रक्रियात्मक" भाषाओं को कई OO भाषाओं की तुलना में RDBMS के साथ अधिक संगत मानते हैं; या सुझाव दें कि कम OO शैली का उपयोग किया जाना चाहिए। (विशेष रूप से, यह तर्क दिया जाता है कि एप्लिकेशन कोड में लंबे समय तक रहने वाले डोमेन ऑब्जेक्ट मौजूद नहीं होने चाहिए; ऐसी कोई भी ऑब्जेक्ट जो मौजूद है, उसे तब बनाया जाना चाहिए जब कोई क्वेरी की जाती है और लेनदेन या कार्य पूरा होने पर उसका निपटान किया जाना चाहिए)। इसके विपरीत, कुछ OO समर्थकों का तर्क है कि OODBMS जैसे अधिक OO-अनुकूल दृढ़ता तंत्र को विकसित और उपयोग किया जाना चाहिए, और संबंधपरक तकनीक को चरणबद्ध तरीके से समाप्त किया जाना चाहिए। कई (यदि अधिकतर नहीं) प्रोग्रामर और डीबीए इनमें से कोई भी दृष्टिकोण नहीं रखते हैं; और वस्तु-संबंधपरक प्रतिबाधा बेमेल को जीवन के मात्र तथ्य के रूप में देखें जिससे सूचना प्रौद्योगिकी को निपटना है।
यह भी तर्क दिया जाता है कि ओ/आर मैपिंग से कुछ स्थितियों में फायदा हो रहा है, लेकिन संभवत: इसकी अधिक बिक्री हो रही है: इसमें कमियों के अलावा फायदे भी हैं। संशयवादियों का कहना है कि इसका उपयोग करने से पहले सावधानी से सोचना उचित है, क्योंकि कुछ मामलों में इसका मूल्य थोड़ा बढ़ जाएगा।[9]
यह भी देखें
- ऑब्जेक्ट-रिलेशनल मैपिंग – Programming technique
- ऑब्जेक्ट-रिलेशनल डेटाबेस - डेटाबेस प्रबंधन प्रणाली
संदर्भ
- ↑ A classification of object–relational impedance mismatch. Ireland, Christopher; Bowers, David; Newton, Mike and Waugh, Kevin (2009). A classification of object–relational impedance mismatch. In: First International Conference on Advances in Databases, Knowledge, and Data Applications (DBKDA), 1-6 Mar 2009, Cancun, Mexico.
- ↑ C. J. Date, Relational Database Writings
- ↑ Object–Relational Mapping Revisited - A Quantitative Study on the Impact of Database Technology on O/R Mapping Strategies. M Lorenz, JP Rudolph, G Hesse, M Uflacker, H Plattner. Hawaii International Conference on System Sciences (HICSS), 4877-4886 (DOI:10.24251/hicss.2017.592)
- ↑ Date, Christopher ‘Chris’ J; Pascal, Fabian (2012-08-12) [2005], "Type vs. Domain and Class", Database debunkings (World Wide Web log), Google, retrieved 12 September 2012.
- ↑ ——— (2006), "4. On the notion of logical difference", Date on Database: writings 2000–2006, The expert’s voice in database; Relational database select writings, USA: Apress, p. 39, ISBN 978-1-59059-746-0,
Class seems to be indistinguishable from type, as that term is classically understood
. - ↑ ——— (2004), "26. Object/Relational databases", An introduction to database systems (8th ed.), Pearson Addison Wesley, p. 859, ISBN 978-0-321-19784-9,
...any such rapprochement should be firmly based on the relational model
. - ↑ Date, Christopher ‘Chris’ J; Darwen, Hugh, "2. Objects and Relations", The Third Manifesto,
The first great blunder
- ↑ Neward, Ted (2006-06-26). "कंप्यूटर विज्ञान का वियतनाम" (PDF). Interoperability Happens. Retrieved 2010-06-02.
- ↑ Johnson, Rod (2002). J2EE Design and Development. Wrox Press. p. 256. ISBN 9781861007841.
बाहरी संबंध
- The Object–Relational Impedance Mismatch – Agile Data Essay
- The Vietnam of Computer Science – Examples of mismatch problems
