मुझे कैसे पता चलेगा कि मेरा डेटा प्रकृति में संबंधपरक या ऑब्जेक्ट ओरिएंटेड है?

17

जरा इन लाइनों को पढ़ें-

यदि आपका डेटा प्रकृति में ऑब्जेक्ट है, तो ऑब्जेक्ट स्टोर ("NoSQL") का उपयोग करें। वे रिलेशनल डेटाबेस की तुलना में बहुत तेज़ होंगे।

यदि आपका डेटा प्रकृति से संबंधित है, तो रिलेशनल डेटाबेस का ओवरहेड इसके लायक है।

from-

http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern

तो, मुझे कैसे पता चलेगा कि मेरा डेटा प्रकृति से संबंधित है या वस्तु-उन्मुख है?

object-oriented database relational-database

— गुलशन
स्रोत

हमें अपने डेटा के बारे में अधिक बताएं ...

— FrustratedWithFormsDesigner

7

@FrustratedWithFormsDesigner मुझे लगता है कि वह सामान्य दिशानिर्देशों की तलाश कर रहा है।

— सी। रॉस

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

— FrustratedWithFormsDesigner

बस यह लिंक मिल गया। आशा है कि इसका उत्तर देने के संकेत हैं- highscalability.com/blog/2011/6/15/…

— गुलशन

17

टुकड़ों में गोली लगने के जोखिम पर, मैं एक सादे अंग्रेजी की कोशिश करूँगा।

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

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

मुझे यह कहना होगा कि मेरे दृष्टिकोण से इन दोनों को अलग करने वाली कोई सख्त रेखा नहीं है। आप शायद किसी भी संख्या के उदाहरण पा सकते हैं जो दो चरम सीमाओं के बीच कहीं भी आते हैं।

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

— wolfgangsz
स्रोत

1

वास्तव में कोई है जो शुरू में सवाल की सादगी पर झल्लाता था, मुझे ब्रावो को समझने योग्य और व्यावहारिक जवाब के लिए कहना पड़ता है। आपको किताबें लिखने में देखना चाहिए।

— फिलिप

क्या हम इसे "संबंधपरक डिजाइन में बहुत सारे लेफ्टिनेंट जॉन्स होने" के लिए सारांशित कर सकते हैं?

— गुलशन

मुझे ऐसा सरलीकरण करने में संकोच होगा। यह लक्षणों में से एक है, लेकिन केवल एक ही नहीं।

— वुल्फगैंग्ज़

उदाहरण के एक बिट कृपया?

— गुलशन

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

— वुल्फगैंग्ज़

5

डेटा दोनों है।

(कड़ाई से बोलते हुए यह प्रकृति में वस्तु नहीं हो सकता क्योंकि इसमें व्यवहार का अभाव है, लेकिन हम नाइटिक नहीं करेंगे)।

RDBMS या NoSQL डेटाबेस में डेटा के भंडारण के बारे में निर्णय इस बात पर अधिक निर्भर करता है कि आप डेटा का उपयोग करने का इरादा रखते हैं , बजाय डेटा के वास्तविक 'प्रकृति' के।

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

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

बेशक, आप विभिन्न कारणों से दोनों में डेटा स्टोर कर सकते हैं, लेकिन इसकी अपनी कमियां हैं।

— साइमन मुनरो
स्रोत

2

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

ऑब्जेक्ट का स्टोर / NoSql का कथन कुछ प्रकार के डेटा के लिए रिलेशनल से तेज होगा, बस गलत है। क्या मायने रखता है कि आपका एप्लिकेशन डेटा का उपयोग कैसे करता है, न कि डेटा का ही रूप। एक ऑब्जेक्ट स्टोर एक यूनिट के रूप में संग्रहीत ऑब्जेक्ट ग्राफ़ को लोड करने में तेज़ होगा, लेकिन कई ऑब्जेक्ट्स पर तदर्थ क्वेरी करने या कई ऑब्जेक्ट पर गुणों को अपडेट करने में बहुत धीमा होगा।

— JacquesB
स्रोत

0

मुझे लगता है कि लेख की मुख्य पंक्ति यह है:

"Likewise, sometimes the output will be a single object X, which is easy to represent. But sometimes the output will be a grid of aggregate data, or a single integer count"

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

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

— ईवान
स्रोत