ऑब्जेक्ट उन्मुख डेटाबेस से संबंध डेटाबेस अधिक आम क्यों हैं?आरओडीएमएस के रूप में व्यापक रूप से ओओडीबीएमएस क्यों नहीं हैं?
यदि ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग प्रतिमान इतना व्यापक है, तो क्या हमें बहुत सारे ओओडीबीएमएस नहीं दिखना चाहिए? क्या वे आरडीबीएमएस + ओआर/एम से बेहतर प्रदर्शन नहीं करेंगे?
आरडीबीएमएस ने लोकप्रियता बरकरार रखने का एक कारण यह है कि यह स्थापित तकनीक है, अच्छी तरह से समझी गई है और एक मानक भाषा (एसक्यूएल) है जो कई विक्रेताओं का समर्थन करती है। इसमें ओडीबीसी और जेडीबीसी जैसे कुछ अच्छे इंटरफेस भी हैं जो इसे विभिन्न भाषाओं से अच्छी तरह से जोड़ते हैं। एक स्थिर एपीआई एक प्रौद्योगिकी प्रभावशाली रखने में एक मजबूत कारक है।
इसके विपरीत, ओओडीबीएमएस के लिए कोई स्पष्ट मॉडल नहीं है, न ही कोई मानक भाषा है, न ही कोई मानक एपीआई है। एक अग्रणी विक्रेता कार्यान्वयन करके एक वास्तविक तथ्य भी नहीं है।
ओओडीबीएमएस अवधारणा RDBMS + ORM से बेहतर प्रदर्शन कर सकता है। यह पूरी तरह कार्यान्वयन पर निर्भर करता है। लेकिन यह भी सच है कि ओओडीबीएमएस उन समस्याओं के एक ही सेट को हल नहीं करता है जो आरडीबीएमएस हल करने में अच्छे हैं। डेटा प्रबंधन समाधान द्वारा लागू संदर्भित अखंडता और रिलेशनल हेडर होने पर कुछ डेटा प्रबंधन कार्य बहुत आसान होते हैं। ये विशेषताएं ओओडीबीएमएस मॉडल (कम से कम अब तक) में अनुपस्थित हैं।
ब्लॉग पर बहुत शोर है जो डेटाबेस के संबंध में अप्रचलित हैं, लेकिन आरडीबीएमएस डेटा प्रबंधन कार्यों के एक बड़े बहुमत के लिए सबसे अच्छा सामान्य उद्देश्य समाधान है।
मुझे लगता है कि यह
का एक मामला है इसे तोड़ दिया नहीं है, तो इसे बदल नहीं है।
रिलेशनल डेटाबेस अत्यधिक शामिल हैं।
एक शब्द
अधिकांश व्यवसायों (एक शुक्रवार की रात < जी > पर बड़ा शब्द) इंटरोऑपरेबिलिटी में आरडीबीएमएस पर चल रहे विरासत प्रणालियों के साथ काम करना है। अगर वे ओओडीबीएमएस का उपयोग करना चाहते थे, तो उन्हें अभी भी कुछ कार्यों के लिए आरडीबीएमएस तक पहुंच की आवश्यकता होगी। दो से डेटा तक पहुंचने का एक तरीका बनाए रखना आसान है।
जब आपके पास ओओडीबीएमएस दुनिया में ओरेकल और एसक्यूएल सर्वर जैसे बड़े नाम हैं और विभिन्न वातावरणों में सिद्ध प्रदर्शन है, तो आप उन्हें और अधिक प्रोजेक्ट देखेंगे।
डेटा अक्सर अधिक रहता है और कार्यक्रम से अधिक महत्वपूर्ण है। तो अगर आप आज ग्रीनफील्ड विकास शुरू करते हैं तो आपको समग्र तस्वीर पर विचार करना होगा। आरडीबीएम सिस्टम के साथ काम कर रहे अधिक टूल्स, प्रोसेस और अनुभवी लोग हैं। कार्यक्रम से परे सोचें, क्षमता नियोजन, डेटा खनन, रिपोर्टिंग, ईटीएल, अन्य डेटा स्रोतों के साथ एकीकरण आदि के बारे में सोचें। आपकी कंपनी किसी अन्य कंपनी को कैसे प्राप्त कर रही है और इस प्रकार आपके कार्यक्रम में उनके सभी संबंधित डेटा ला रही है। आरडीबीएमएस और संबंधित उपकरण इतने व्यस्त, सिद्ध और शक्तिशाली हैं कि मुझे किसी और चीज का उपयोग करने में कोई रणनीतिक भावना नहीं है। कुछ छोटे आला में शायद सामान्य रूप से नहीं।
"डेटा अक्सर अधिक रहता है और कार्यक्रम से अधिक महत्वपूर्ण है।" - तथास्तु। मध्य स्तर आते हैं और जाते हैं, लेकिन डेटा हमेशा के लिए रहता है। – duffymo
ओओडीबीएमएस आरडीबीएमएस की तुलना में किसी विशिष्ट भाषा से बंधे नहीं हैं, कार्यान्वयन-विशिष्ट संग्रहित प्रक्रियाओं के लिए बाध्य हैं। –
सिद्धांत में आप सही हैं लेकिन व्यावहारिक रूप से कुछ अच्छी तरह से ज्ञात आरडीबीएमएस कार्यान्वयन हैं और जो उपकरण, एक विशाल ज्ञान आधार और अनुभवी लोगों द्वारा समर्थित हैं। मेरी कंपनी सिर्फ एक कॉर्पोरेट विलय हो गई और हमने अन्य कंपनी के डेटाबेस से डेटा को हमारे डेटाबेस में आयात किया (बहुत सारे परिवर्तन, डेटा मालिश और सफाई के साथ)। दोनों कंपनी ने ओरेकल का इस्तेमाल किया और इससे चीजें निश्चित रूप से आसान हो गईं, अगर दूसरी कंपनी ने थोड़ा ज्ञात डेटाबेस इस्तेमाल किया हो। – softveda
ऑब्जेक्ट डेटाबेस में ज्यामिति का प्रतिनिधित्व करने जैसी समस्याओं के लिए बहुत अच्छा आला है। सीएडी सिस्टम, जहां ऑब्जेक्ट ग्राफ वास्तव में बहुत गहरे हो सकते हैं। अधिकांश संबंध प्रणाली में लगभग 7 तालिकाओं के लिए प्रदर्शन में तेजी से गिरावट आती है, इसलिए सीएडी में गहराई से आत्म-संदर्भित संरचनाएं ऑब्जेक्ट डेटाबेस में बेहतर प्रदर्शन करती हैं।
लेकिन वित्तीय डेटा जैसे महत्वपूर्ण अनुप्रयोग स्वयं को एक संबंधपरक प्रतिनिधित्व के लिए उधार देते हैं। रिलेशनल मॉडल में एक दृढ़ गणितीय आधार है, और एसक्यूएल एक सफल और लोकप्रिय भाषा है। बैंकों, ब्रोकरेज और बीमा कंपनियों जैसे वित्तीय संस्थानों के लिए आरडीबीएमएस से दूर जाने के लिए बहुत कम प्रोत्साहन है।
मैंने जो सबसे बड़ी समस्या देखी है वह मानकीकरण की कमी है। आरडीबीएमएस की दुनिया में, यदि आप एसक्यूएल जानते हैं तो आप किसी भी यादृच्छिक डेटाबेस के साथ बहुत दूर हो सकते हैं। वे मूल रूप से मामूली विविधताओं के साथ इसे लागू करते हैं। मुझे एक मौजूदा आरडीबीएमएस नहीं पता है जो एसक्यूएल नहीं करता है: आप लगभग "आरडीबीएमएस" और "एसक्यूएल" का एक दूसरे से उपयोग कर सकते हैं।
ओओडीबीएमएस के लिए सबसे नज़दीकी चीज शायद ओक्यूएल है, जो पूरी तरह विफल रही है।
कोई डेटाबेस कभी भी इसमें बहुत अधिक लागू नहीं हुआ है। मैंने कुछ साल पहले एक बहुत अच्छा वाणिज्यिक ओओडीबीएमएस का इस्तेमाल किया था, लेकिन (2007 या उससे भी अधिक के रूप में, और यह 8 या 9 संस्करण के प्रमुख संस्करण पर था) यह किसी ऑब्जेक्ट के नाम से पूछताछ का समर्थन भी नहीं करता था। मैनुअल ने कहा कि ओक्यूएल के इस हिस्से को वे अभी तक नहीं मिला था। (मुझे यकीन नहीं है, लेकिन हो सकता है कि आप ऐसा करने के लिए देशी कॉल में उतर सकें।)
अधिकांश ऑब्जेक्ट डेटाबेस जिन्हें मैंने हाल ही में देखा है, ओक्यूएल जैसी क्वेरी भाषा की बजाय मूल भाषा इंटरफेस है। मैंने जिस प्रणाली का उपयोग किया, उदाहरण के लिए, समर्थित (केवल!) पर्ल और वीबी, आईआईआरसी। अपने दर्शकों को केवल कुछ भाषाओं तक सीमित करना (या उन्हें रैपर लिखने के लिए मजबूर करना, जैसा कि हमने किया) दोस्तों को जीतने का तरीका नहीं है।
इस वजह से, कोई प्रतिस्पर्धा नहीं है, और इसलिए कोई आसान बैकअप योजना नहीं है। यदि आप एमएस-एसक्यूएल में अपना डेटा डालते हैं और माइक्रोसॉफ्ट ने इसे समर्थन देना बंद कर दिया है, तो आप शायद अपने डेटा को पोस्टग्रेज़ में डंप कर सकते हैं और बिना किसी परेशानी के अपने प्रश्नों को पोर्ट कर सकते हैं। (यदि आपके पास बहुत सारे प्रश्न हैं, तो मुझे बहुत काम हो सकता है, लेकिन मुझे संदेह नहीं है कि आप इसे कर सकते हैं। यह दर्द है, लेकिन तकनीकी रूप से चुनौतीपूर्ण नहीं है।) या ओरेकल, या MySQL, या कई अन्य, दोनों वाणिज्यिक और मुफ़्त।
ओओडीबीएमएस के साथ ऐसी कोई चीज़ मौजूद नहीं है: यदि आप जिस व्यक्ति का उपयोग कर रहे हैं वह पेट-अप हो जाता है, या वे इसे उस दिशा में ले जाते हैं जो आपके लिए उपयोगी नहीं है, या आपको लगता है कि इसमें आपकी एक महत्वपूर्ण विशेषता नहीं है, तो आप कर सकते हैं अपने डेटा को एक प्रतिस्पर्धी ओओडीबीएमएस में डंप न करें और अपने प्रश्नों को बंद करें। इसके बजाए, आप कोर लाइब्रेरी को बदलने और बड़े पैमाने पर आर्किटेक्चर परिवर्तन करने के बारे में बात कर रहे हैं। तो वास्तव में, आप एक वाणिज्यिक ओओडीबीएमएस तक सीमित हैं, जिन्हें आप वास्तव में भरोसा करते हैं (क्या आप यहां तक कि एक नाम भी दे सकते हैं?), या ओपन-सोर्स ओओडीबीएमएस जिन्हें आप अपनी टीम पर भरोसा करते हैं, जब चीजें खराब होती हैं।
अगर यह एफयूडी की तरह लगता है, क्षमा करें, तो मुझे इसका इरादा नहीं था। लेकिन मैं वहां गया हूं, और एक परियोजना प्रबंधन परिप्रेक्ष्य से मैं वापस जाने में संकोच करता हूं, भले ही प्रोग्रामिंग वातावरण अद्भुत हो। इसके बारे में सोचने का एक और तरीका यह है कि: यह कितना अच्छा विचार है कि यह कितना लोकप्रिय कार्यात्मक प्रोग्रामिंग है। ओओडीबीएमएस इस तरह हैं, लेकिन बदतर, क्योंकि यह सिर्फ आपका कोड नहीं है, बल्कि आपका कोड और आपका डेटा है। मैं खुशी से आज Erlang में एक प्रमुख परियोजना शुरू कर दूंगा, लेकिन मैं अभी भी एक ओओडीबीएमएस का उपयोग करने में संकोच करता हूं।
ओओडीबीएमएस विक्रेता: इसे बदलने के लिए, आपको make it easy to leave you for your competitors की आवश्यकता है। आप ओक्यूएल खोद सकते हैं और वास्तव में इसे कार्यान्वित कर सकते हैं, या ओडीबीसी, या जो कुछ भी एपीआई स्तर पर कर सकते हैं। यहां तक कि एक मानक डंप प्रारूप (JSON का उपयोग कर?), और कई ओओडीबीएमएस के लिए आयात/निर्यात के लिए उपकरण, एक महान शुरुआत होगी।
परीक्षण उदाहरणों के लिए ओओडीबी और आरडीबी बहुत अलग हो सकते हैं। विशेष रूप से यदि आप पर्याप्त मात्रा में डेटा के साथ काम कर रहे हैं, तो आप इसे एक बार में स्मृति में पढ़ सकते हैं और इसे एक साथ लिख सकते हैं। लेकिन आखिरकार ओओडीबी को बहुत ही आरडीबी जैसी प्रारूप में डेटा को बचाने की जरूरत है - वे इतने अलग नहीं हैं।
किसी ऑब्जेक्ट में उपयोग किए जा सकने वाले ऑब्जेक्ट्स के मनमाना ग्राफ पर विचार करें। प्रत्येक ऑब्जेक्ट को कई अन्य ऑब्जेक्ट्स द्वारा संदर्भित किया जा सकता है।जब आप ऑब्जेक्ट्स का ग्राफ़ सहेजते हैं, तो आप संदर्भित हर बार वस्तुओं को बार-बार सहेजना नहीं चाहते हैं। एक बात के लिए, यदि आपके पास किसी प्रकार का लूप या आत्म-संदर्भ था तो आपकी सेव-ऑब्जेक्ट विधि एक अनंत लूप में जाएगी। लेकिन सामान्य मामले में, यह अंतरिक्ष की बर्बादी है। इसके बजाए, किसी भी महत्वपूर्ण डेटा स्टोर को प्रत्येक ऑब्जेक्ट को संग्रहीत करने के लिए एक अद्वितीय पहचानकर्ता घोषित करने की आवश्यकता होती है (एक कुंजी, आमतौर पर आरडीबीएमएस शर्तों में एक सरोगेट कुंजी)। एक अन्य ऑब्जेक्ट जो संदर्भ देता है वह ऑब्जेक्ट प्रकार और कुंजी को सहेजता है, यह पूरे ऑब्जेक्ट को बार-बार सहेजता नहीं है। तो यहां हमने अपने गैर आरडीबी ऑब्जेक्ट-स्टोर में विदेशी कुंजी को फिर से बनाया है।
अगला, दिखाएं कि हम ऑब्जेक्ट्स (ए 1, ए 2, ए 3 ...) की एक सूची स्टोर करना चाहते हैं जो किसी अन्य ऑब्जेक्ट (बी) से संबंधित हैं। हमने पहले से ही स्थापित किया है कि हम ऑब्जेक्ट्स को दो बार सहेजने के बजाय चाबियाँ स्टोर करेंगे। लेकिन क्या आप ऑब्जेक्ट बी पर ऑब्जेक्ट्स ए 1, ए 2, ए 3 ... पर ऑब्जेक्ट्स स्टोर करते हैं, या आप बी पर ऑब्जेक्ट करने के लिए कुंजी स्टोर करते हैं? यदि आप उन्हें पहली तरह से स्टोर करते हैं, और आपके पास सभी ए की इच्छा है, तो आप जल्दी से संबंधित बी को पकड़ सकते हैं। दूसरी तरफ रिवर्स सत्य है। लेकिन किसी भी तरह से एक तरफा सौदा है। यदि आप जो संग्रहित करते हैं उसके विपरीत और आपकी ऑब्जेक्ट्स को XML या JSON के रूप में संग्रहीत किया जाता है, तो यह पूछना चाहता है कि यह प्रत्येक फ़ाइल में कुंजी खोजने के लिए सबसे अप्रासंगिक जानकारी के माध्यम से बहुत अक्षम अक्षम है। क्या उन्हें एक प्रारूप में स्टोर करना बेहतर नहीं होगा जहां प्रत्येक फ़ील्ड अलग हो, जैसे किसी तालिका में कॉलम?
कई से अधिक रिश्ते में, या एक मामला जहां आपको दोनों दिशाओं में बड़ी संख्या में वस्तुओं को खोजने की आवश्यकता है, यह रणनीति बहुत अक्षम हो जाती है। एकमात्र प्रदर्शन समाधान रिश्ते को स्टोर करने के लिए एक सहायक वस्तु बनाना है, प्रत्येक संबंध के लिए एक फ़ाइल के साथ, जिसमें फ़ाइल ए की कुंजी और बी की कुंजी होती है ताकि उन्हें जल्दी से देखा जा सके। हमने अभी क्रॉस-रेफरेंस टेबल को फिर से शुरू किया है।
कॉलम, अद्वितीय पहचानकर्ता (कुंजी), क्रॉस-रेफरेंस टेबल के साथ टेबल्स ... ऑब्जेक्ट्स को संग्रहीत करने के लिए ये मूलभूत आवश्यकताएं हैं ताकि उन्हें कुशलता से पुनर्प्राप्त किया जा सके। हम्म ... क्या यह कुछ परिचित की तरह लगता है? एक रिलेशनल डेटाबेस बिल्कुल इस कार्यक्षमता प्रदान करता है। इसके अलावा, कई विक्रेताओं ने दशकों तक बैकअप, प्रतिकृति, क्लस्टरिंग, पूछताछ इत्यादि के लिए सबसे अच्छे डेटा स्टोरेज और पुनर्प्राप्ति प्रदान करने के लिए प्रतिस्पर्धा की है। यह एक नई तकनीक के साथ प्रतिस्पर्धा करने के लिए बहुत कुछ है। और अंत में मैं कह रहा हूं कि आरडीबीएमएस मूल रूप से कुशल वस्तु भंडारण की समस्या का वास्तव में अच्छा समाधान है।
यही कारण है कि हाइबरनेट की तरह कुछ मौजूद है - एक ऑब्जेक्ट उन्मुख इंटरफेस को एक कुशल आरडीबीएमएस स्टोरेज सिस्टम पर डालने के लिए।
ओओडीबी आरडीबी से बेहतर प्रदर्शन नहीं कर सकता क्योंकि वे मूल रूप से अलग नहीं हैं।
आरडीबी यहां रहने के लिए हैं क्योंकि वस्तुओं के बड़े ग्राफ को सहेजने और पुनर्प्राप्ति दोनों के लिए अंतरिक्ष-कुशल और समय-कुशल, और गलती सहनशील भी है और डेटा अखंडता की कुछ गारंटी है समस्या यह है कि आरडीबी को डिजाइन किया गया था पहली जगह में हल करें। यही कारण है कि जेपीए और हाइबरनेट यहां रहने के लिए भी हैं - क्योंकि वे ऑब्जेक्ट और डेटा के संबंधपरक मॉडल के बीच के अंतर को पुल करते हैं। स्मृति में हेरफेर की आसानी के लिए ऑब्जेक्ट मॉडल, और दृढ़ता के लिए संबंधपरक।
"यदि यह तोड़ नहीं है तो इसे बदलना नहीं है" इतना बेवकूफ है ... कुछ बेहतर क्यों बना रहा है, या सॉफ्टवेयर विकसित करना एक बुरी चीज है। जब मैंने इसे बदल दिया तो मेरा आखिरी कंप्यूटर तोड़ नहीं था, बस धीमा था !!!!एक डेवलपर के रूप में मेरा लक्ष्य बेहतर, अधिक कुशल समाधान करने का प्रयास करना है। – billy