मैं आज एडवेंचरवर्क्स डेटाबेस के आसपास घूम रहा था और मैंने देखा कि कई टेबल ( HumanResources.JobCandidateऔर Sales.Individualउदाहरण के लिए) में एक कॉलम है जो xml डेटा स्टोर कर रहा है।
मुझे पता है कि मूल रूप से डेटाबेस तालिका पंक्ति के किसी अन्य तालिका के कॉलम में डेटा के मूल्य को संग्रहीत करने का क्या फायदा है? क्या इस जानकारी को छोड़ना मुश्किल नहीं है? या यह धारणा है कि डेटा को क्वेर करने की आवश्यकता नहीं होगी और बस संग्रहीत करने की आवश्यकता है?
जवाबों:
क्योंकि सभी डेटा को रिलेशनलली स्टोर करने की जरूरत नहीं होती है और डेटा को प्रोसेस करने के लिए कोड लिखना होता है, जिसे रिलेशनल स्टोरेज के लिए एक्सएमएल के रूप में पास किया जाता है, इसमें समय लगता है (और बहुत थकाऊ)। यह विशेष रूप से सच है जब बहुत सारे XML डेटा सिस्टम से आ रहे हैं जो बड़ी जेनेरिक प्रतिक्रियाओं को फेंक रहे हैं।
मैंने अक्सर ऐसी स्थितियों को देखा है जहां एक संदेश किसी अन्य प्रणाली से प्राप्त होता है और हम इसमें शामिल 98% के बारे में परवाह नहीं करते हैं। इसलिए हम इसे उस 2% को विभाजित करने के लिए पार्स करते हैं जिसके बारे में हम परवाह करते हैं, उस संबंध को स्टोर करें और फिर पूरे संदेश को स्टोर करें यदि हमें शेष 98% में से किसी की आवश्यकता है।
और एसक्यूएल सर्वर आपको टी-एसक्यूएल में एक्सएमएल के साथ काम करने के लिए कुछ ओके-ईश टूल और सिंटैक्स देता है, इसलिए ऐसा नहीं है कि यह विज्ञापन-हॉक प्रश्नों के लिए पूरी तरह से व्यावहारिक पहुंच से परे है जिस तरह से यदि आप स्टोर कर रहे थे, तो कह सकते हैं, सामग्री एक सीएसवी की।
और यह संभावना को बाहर करता है कि आप वास्तव में क्या स्टोर करना चाहते हैं एक्सएमएल (उदाहरण के लिए समर्थन और डिबग उद्देश्यों के लिए) ...
यदि डेटा प्रारूप अस्थिर है और संभव परिवर्तन के अधीन है, तो आप इसे XML के रूप में एक साथ रखना चाहते हैं और इस रूप में डेटाबेस में डाल सकते हैं ताकि भविष्य के डेटाबेस स्कीमा परिवर्तन से बचा जा सके।
उसी स्पर्शरेखा पर, यदि डेटा को किसी बाहरी सिस्टम द्वारा आपूर्ति की जाती है और फिर से इसका उपभोग किया जाता है, और वे आपको एक स्थायी प्रारूप प्रदान करने में असमर्थ होते हैं, तो आप यही करेंगे।
क्या इस जानकारी को छोड़ना मुश्किल नहीं है?
SQL सर्वर XML फ़ील्ड और वेरिएबल्स को क्वेरी कर सकता है। जरूरी नहीं कि मुश्किल हो, लेकिन अधिक काम, हां। लेकिन उल्लेखनीय है।
मेरे अनुभव में, XML डेटा को आमतौर पर संग्रहीत किया जाता है और शायद ही कभी इसे नियंत्रित किया जाता है, लेकिन अक्सर आवश्यक होने पर निकाला जाता है, आमतौर पर जब किसी अन्य प्रणाली को कुछ डेटा के XML प्रतिनिधित्व की आवश्यकता होती है जो रिलेशनल डेटा से ऑन-द-फ्लाई उत्पन्न करना मुश्किल या असंभव हो सकता है। XML डेटा किसी अन्य प्रक्रिया से पहले से आबाद हो सकता है।
यदि आप अपने डेटा को एक बाइनरी स्ट्रीम में एक ब्लॉब में संग्रहीत करने की कल्पना कर सकते हैं, तो मैं कल्पना करूँगा कि आप अपने डेटा को एक बूँद में xml प्रारूप में संग्रहीत करने की कल्पना कर सकते हैं।
बेशक, कल्पना की कल्पना में बहुत सी चीजें सबसे अच्छी हैं।
उदाहरण के लिए, इलेक्ट्रॉनिक मेडिकल रिकॉर्ड्स कहें:
चूंकि आप सबसे अधिक संभावना डेटाबेस में एक क्षेत्र में ASCII HL7 V2.x स्टोर करते हैं। संभवतः आप किसी डेटाबेस में एक क्षेत्र में HL7 V3.0 को स्टोर करने के लिए उपयुक्त नहीं होंगे।
तो लाभ सुविधा है।
मैं वर्तमान में एक ऐसी परियोजना पर काम कर रहा हूं जो ऐसा करती है। हमारे पास ऐसे डेटा हैं जिन्हें कई बार संसाधित करने की आवश्यकता होती है, जो रिलेशनल रूप से संग्रहीत होते हैं। हालांकि, प्रसंस्करण जावा में किया जाता है, और वहां एक्सएमएल के साथ काम करना आसान है। इसलिए, हम रिलेशनल डेटा के माध्यम से एक बार पास करते हैं और इसे एक तालिका में XML के रूप में संग्रहीत करते हैं। फिर हम हर बार डेटा को पुनर्प्राप्त करने के बजाय एक गैर-जॉइनिंग क्वेरी के साथ जावा में उस डेटा को संसाधित कर सकते हैं, और उसी डेटा को हमारे दिल की सामग्री पर और फिर से संसाधित कर सकते हैं। यह बहुत सरल और अधिक कुशल है।
XML को संग्रहीत करने का एक अच्छा उदाहरण है जब आप डेटाबेस में UI स्थिति को बनाए रखना चाहते हैं। सभी एप्लिकेशन दृश्यों की स्थिति को क्रमबद्ध और डेटाबेस में संग्रहीत किया जाता है और एक्सएमएल को क्वेरी करने की कोई आवश्यकता नहीं है। UI स्थिति से मेरा मतलब है, देखने का क्रम, खिड़कियों का आकार आदि।
अक्सर आपको मिश्रित डेटा मिलता है जो XML और संबंधपरक दोनों होता है। (इसका एक बढ़िया उदाहरण एक दस्तावेज़ स्टोर है जहां प्रत्येक दस्तावेज़ में मेटाडेटा फ़ील्ड जैसे शीर्षक, निर्माण की तिथि, स्वामी और इसी तरह हो सकते हैं।)
इस बिंदु पर आपको तीन विकल्पों में से चुनना होगा:
विकल्प 3 शायद सबसे साफ है, लेकिन सबसे महंगी और लागू करने के लिए सबसे कठिन है, साथ ही आप जरूरी नहीं कि एक बहुत बड़ी प्रणाली में वितरित लेनदेन चाहते हैं। विकल्प 2 बहुत अच्छा नहीं है क्योंकि मूल XML डेटाबेस आमतौर पर रिलेशनल डेटा (जो आप खोजों में उपयोग करने की अधिक संभावना रखते हैं) पर बेहद खराब हैं और प्रौद्योगिकी रिलेशनल डीबी की तुलना में कुल मिलाकर कम परिपक्व है।
तो यह आपको विकल्प 1 के साथ छोड़ देता है क्योंकि निश्चित रूप से सबसे अच्छा समाधान नहीं है, लेकिन शायद सबसे कम बुरा है।
मेरे अनुभव में, एक डेटाबेस में XML का उपयोग करना समाप्त हो रहा है क्योंकि डेटा का स्रोत इसे कैसे संग्रहीत करता है, या आप इसे मौजूदा डेटाबेस में इस तरह से कार्यक्षमता बढ़ाने के लिए जोड़ रहे हैं कि समर्थन करने के लिए बहुत सारे डेटाबेस प्रोग्रामिंग की आवश्यकता नहीं होगी ।
यदि आप नए डेटा पर बार-बार खोज करने जा रहे हैं, तो इसके बजाय XML को इसके घटक भागों में विभाजित करने का कोई मतलब हो सकता है। यदि नहीं, तो यह आमतौर पर बदले हुए डेटा को बचाने का एक उपयोगी तरीका हो सकता है।
आशा है कि यह मदद करता है, जेफ
दस्तावेज़-उन्मुख डेटास्टोर्स (उर्फ नोस्कल) इन दिनों बहुत लोकप्रिय हैं:
http://en.wikipedia.org/wiki/Document-oriented_database
कोई कारण नहीं है कि आप संबंधपरक डेटाबेस में दस्तावेज़-उन्मुख योजना को नियोजित नहीं कर सकते हैं। आपको मानगो जैसी किसी चीज़ की तुलना में सभी समान लाभ नहीं मिल सकते हैं, लेकिन आपके पास कमियां भी नहीं होंगी।
एक लंबे समय के लिए, यदि आप दस्तावेज़-उन्मुख भंडारण का उपयोग करना चाहते हैं, तो आपकी एकमात्र पसंद एक बड़े कॉलम में संरचित डेटा (एक्सएमएल की तरह) को हिला रही थी। संबंधपरक डेटाबेस उस समर्थन के लिए अनुक्रमण और मिलान जैसी सुविधाएँ जोड़ रहे हैं।
कंट्रास्ट कि मानगो के साथ, जहाँ वे केवल डेटाबेस में काम करते हैं दस्तावेज हैं। लेकिन यह एक और विषय है।
संपादित करें: दस्तावेज़-उन्मुख का मुख्य विचार यह है: आप डेटा को बाहर निकालते हैं, इसे हेरफेर करते हैं, और इसे वापस पूरे में हिलाते हैं। कभी-कभी, जैसे जब आप ग्राहक को दस्तावेज़ प्रेषित कर रहे होते हैं, तो आप पूरी चीज़ को एक बूँद के रूप में भेजना चाहते हैं और उन्हें इससे निपटने देते हैं। लाभ (और दोष) लचीलापन है। डेटाबेस के बाहर दस्तावेज़ का सत्यापन और शुद्धता की जाती है ।
EDIT EDIT: एक और कंट्रास्ट। एक डेटाबेस कॉलम में जेपीजी इमेज या वर्ड डॉक्स को बचाने की कल्पना करें।
एक पेड़ (एक्सएमएल) को ट्यूपल्स (एक डेटाबेस तालिका) की सूची में संग्रहीत करने के क्या फायदे हैं?
कोई कारण नहीं है कि XML को आपके DBMS से उदाहरण के लिए XPath या SPARQL का उपयोग करने योग्य नहीं होना चाहिए।
जैसा कि मैंने इसे देखा, वे केवल दो अलग-अलग डेटा संरचनाएं हैं। और कोई कारण नहीं है कि उन्हें एक दूसरे में एम्बेड नहीं किया जाना चाहिए।
PostgreSQL में JSON डेटाटाइप को क्यों जोड़ा गया, इसके कारणों को आप देख सकते हैं। मुझे लगता है कि एक ही तर्क के कई लागू होते हैं। सिवाय इसके कि XML / XSD के साथ और भी अधिक सत्यापन संभव है।
वैसे, XML (या JSON) मेटाडेटा को पदानुक्रम के साथ संग्रहीत करने के लिए बहुत अच्छा है। विकल्प क्या हैं? एक मेटाडेटा तालिका जिसमें रिफिड / की / वैल्यू / डेप्थ हो सकती है? यह थोड़ा बोझिल है (लेकिन अगर आपको इसे करने की आवश्यकता है तो क्वेरी के लिए बेहतर है)। दस्तावेज़ के बारे में कुछ xml डेटा संग्रहीत करना (एक दस्तावेज़ तालिका में एक पंक्ति) बहुत सुविधाजनक है जब आप बाहरी तालिका पर भरोसा करने या infos के "प्रकार" में 1 कॉलम जोड़ने के लिए बिना कुछ पदानुक्रमित infos संग्रहीत करना चाहते हैं।
मैं कहता हूं कि यह बुरा व्यवहार था क्योंकि आप अक्षम टैग के साथ कुशल भंडारण को रोक रहे हैं जो कि जानकारी को पार्स करने के लिए प्रयास करने पर वहां होने की आवश्यकता नहीं है। एक्सएमएल में डेटा का वर्णन करने की तुलना में एक छिपी हुई स्टोरेज ओवरहेड है, क्योंकि आपको प्रत्येक पंक्ति के लिए प्रत्येक कॉलम के लिए एक टैग की आवश्यकता होती है। तुलना करके, डेटा को पार्स किया गया और रिलेशनल फॉर्मेट में स्टोर किया गया है, इसका कॉलम नाम ONCE स्टोर किया गया है। एक देव पर एक दर्जन पंक्तियों के लिए। बॉक्स, बड़ी बात है, लेकिन मैंने देखा है कि डेवलपर्स यह अनुमान लगाते हैं कि यह लाखों पंक्तियों के लिए स्केलेबल है। यह कुछ दर्जन जीबी डेटा के लिए 100 जीबी की ओवरहेड का प्रतिनिधित्व कर सकता है, जो परिचालन चुनौतियां पैदा करता है। आप मूल रूप से अपने आप से जिम्मेदारी का निर्वाह कर रहे हैं और उन लोगों पर जोर दे रहे हैं जिन्हें आपके द्वारा लिखे गए बकवास का समर्थन करना है।
तो, क्यों नहीं इसे संचालन डेटा से AWAY, अपने स्वयं के डेटाबेस में संग्रहीत करें? या जैसा कि यह इरादा है - फ्लैट फ़ाइलों में? यह शायद फिर से कभी नहीं देखा जाएगा, इसलिए इसे एक संचालन प्रणाली के प्रदर्शन को मारने से क्यों नहीं हटाया जाए? याद रखें कि XML केवल डेटा के स्कीमा का विवरण प्रदान करने के लिए है जो सिस्टम के बीच भंडारण प्रोटोकॉल अंतर के कारण अन्यथा स्पष्ट नहीं होगा। यह इसकी पूरी बात है, इसके बारे में कुछ भी चतुर नहीं है। डेटा की दी गई राशि के लिए ओवरहेड की राशि को 10x संग्रहीत करने से सिर्फ यह कहा जाता है कि आप एक फूहड़ डेवलपर हैं जो चीजों के बारे में नहीं सोचते हैं और जिस डेटा का आप उपभोग कर रहे हैं उसे संसाधित करने के लिए उत्पन्न नहीं किया जा सकता है, आप क्वेरी प्रारूप के लिए एक समझदार, कुशल, तेज़ में उपयोग कर रहे हैं। परिचालन सहायता पर अपने प्रयास को रोकें, और इस बारे में सोचें कि आप अपने बाद डेटा को बेहतर तरीके से कैसे संभाल सकते हैं। यह मेरा फोन होगा प्राप्त किया। यह प्राप्त करने के बाद XML के रूप में डेटा संग्रहीत करने के लिए कोई बचाव नहीं है, क्योंकि यह अपना उद्देश्य पूरा करता है।