2010-12-09 6 views
15

मैंने कई स्रोतों से सुना है जो डेटाबेस में एक्सएमएल संग्रहीत करना "बुरा" है, लेकिन मैंने कभी भी ऐसा क्यों नहीं देखा है कि यह क्यों है। क्या यह सच है? यदि यह सच है, तो क्या आप समझा सकते हैं क्यों? इसके अलावा, क्या आप मुझे बता सकते हैं कि डेटाबेस में एक्सएमएल स्टोर करने के लिए "अच्छा" मामला क्या है?क्या यह डेटाबेस में एक्सएमएल स्टोर करने के लिए "बुरा" है?

उत्तर

18

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

+4

शायद आपको स्कीमा-कम डेटा स्टोर का उपयोग करने पर विचार करना चाहिए? RavenDB या MongoDB की तरह कुछ? –

+2

यह एक बहुत चालाक समाधान है। प्रश्न - आप ऐसी परिस्थितियों को कैसे संभालेंगे जहां आपको उन विशेषताओं पर चयन करने की आवश्यकता है? – Ender

+1

@Ender - तालिका का क्वेरी पूछे जाने पर क्लाइंट को एक्सएमएल दस्तावेज़ वापस लौटने का प्राथमिक तरीका है, और क्लाइंट एक्सएमएल को आवश्यकतानुसार पारदर्शी करता है। –

2

नहीं, ऐसा नहीं है।

असल में कई डेटाबेस पहले से ही दुकान एक्सएमएल दस्तावेजों

1

मैं भंडारण लगता है कि एक डेटाबेस बुरा होगा के लिए डेटा प्रकार है शायद कारणों (आदि को पार्स) गति के लिए। हालांकि एक अच्छा मामला यह होगा कि यह अर्ध-संरचित मॉडल फिट बैठता है, इस सूचीबद्ध here के कुछ फायदे हैं।

10

एक्सएमएल भंडारण, JSON, YAML, अल्पविराम से अलग की सूची, द्विआधारी धब्बे, या एक डेटाबेस में कुछ और बुरा ... से प्रति नहीं है।

यह क्या एक डेटाबेस (भंडारण डेटा है कि अन्य डेटा से संबंधित है) के लिए है की समझ की कमी से संकेत मिलता है और एकल स्तंभ टेबल data1 कहा जाता है, data2, आदि के साथ डेटाबेस की दृष्टि conjures ... के साथ कर सकते हैं एक्सएमएल एन्कोडेड रिलेशनल डेटा की +5 एमबी प्रविष्टि रखने वाली प्रत्येक तालिका पंक्ति।

दूसरी ओर, इसके कई मान्य मामलों है कि इस तरह की संरचना के लिए बनाया जा सकता है कर रहे हैं - तेजी से बदल रहा विन्यास JSON में प्रतिनिधित्व और एक दो स्तंभ तालिका इस तरह संरचित में संग्रहित किया जा सकता है:

dbo.good_table 
ApplicationID (bigint) 
Configuration (varchar(max)) 

इस तरह उपरोक्त तालिका और एक मेज के बीच अंतर:

dbo.bad_table 
ApplicationID (bigint) 
ApplicationMembers(xml) 

कि good_table, डेटा (विन्यास) के एक टुकड़े के लिए तेजी से पहुँच सक्षम है, जबकि bad_table एक ofttimes expens के रूप में डेटाबेस का उपयोग कर रहा है ive (और धीमी) हार्ड डिस्क।

3

एक्सएमएल अपने आप में एक तरह का भंडारण फ़ाइल है। यह डेटा के परिवहन के लिए सबसे व्यावहारिक रूप से उपयोग किया जाता है, क्योंकि यह डेटा संरचना के लिए एक सामान्य मैकेनिक प्रदान करता है। XML को पढ़ने और लिखने के लिए निश्चित नियम हैं जो XML फ़ाइलों को किसी के द्वारा पढ़ने की अनुमति देते हैं। अन्य आउटपुट प्रारूपों में भी सत्यापन और परिवर्तन अपेक्षाकृत आसान है (xslt का उपयोग करके)। एक्सएमएल, हालांकि, डेटा को स्टोर करने का सबसे अच्छा तरीका नहीं है। यह एक्सएमएल फाइलों को पढ़ने में समय लगता है और वे अपेक्षाकृत अधिक जगह लेते हैं। अपने डेटाबेस में संरचित तरीके से अपने डेटा को स्टोर करना सबसे अच्छा है, और कुछ प्रश्नों से डेटा को एक्सएमएल में निर्यात करें यदि आपको रिपोर्ट में, वेबसाइट पर या अन्य पार्टियों को पास करने की आवश्यकता हो।

एक्सएमएल डेटाबेस हैं, लेकिन वे एक्सएमएल में डेटा भी स्टोर नहीं करते हैं। वे केवल मानक तालिका संरचना के बजाय पदानुक्रमित डेटा (एक्सएमएल एक पदानुक्रमित संरचना) को बचाने और लोड करने का एक तरीका प्रदान करते हैं।

तो यह कहना है कि एक डेटाबेस में एक ब्लॉब में XML सामग्री को संगृहीत करने में आम तौर पर जाने के लिए सही तरीका नहीं है सही है, लेकिन वहाँ हमेशा अपवाद बिल्कुल नहीं है।

एक्सएमएल दूसरों के कहने के विपरीत है - डेटा प्रदर्शित करने का कोई तरीका नहीं। यह डेटा निर्यात (और आयात) करने का एक तरीका है। यह डेटा के परिवहन के लिए एक तार्किक विकल्प है। ऐसा इसलिए है क्योंकि आप इसे निर्यात करने के तरीके में पूरी तरह से लचीला हैं, इसे आसानी से अन्य प्रारूपों में परिवर्तित किया जा सकता है। जैसे, यदि आपके पास वेबशॉप है, और आप अन्य पार्टियों को कीमतें और उत्पाद जानकारी निर्यात करना चाहते हैं, तो आप एक्सएमएल चुन सकते हैं। ये अन्य पार्टियां इस डेटा को उनकी जरूरतों में बदलने के लिए आसान नियम लिख सकती हैं। किसी भी पार्टी को दूसरी तरफ कीमतों को संग्रहीत करने के तरीके को जानना नहीं है, और किसी भी पार्टी को बाइनरी पढ़ने के लिए कुछ कठिन परिश्रम करने के लिए एक जटिल उपकरण लिखना नहीं है जिसे किसी और ने बनाया है।

18

यहाँ कुछ सच में बेवकूफ जवाब नहीं है - एक डेटाबेस का समर्थन करता है डेटा प्रकार नहीं आप इसे का उपयोग करना चाहिए मतलब है सिर्फ इसलिए। इन चीजों को हमेशा विशेषताओं के रूप में जोड़ा जाता है क्योंकि प्रतियोगिता में उन्हें होता है, न कि क्योंकि वे करने के लिए सही काम हैं। सार्वत्रिक चर? ट्रिगर? क्या कोई भी उनकी रक्षा करना चाहेगा क्योंकि आप उनका उपयोग कर सकते हैं और वे वहां हैं?

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

एक्सएमएल डेटा ट्रांसफर प्रोटोकॉल है; चूंकि गोलेज़्रोल ने सही कहा, "यह डेटा निर्यात (और आयात) करने का एक तरीका है" - यानी: यह केवल एक ओवरहेड है जो विभिन्न प्रणालियों के बीच डेटा की संरचना के संचार की सुविधा प्रदान करता है। एक बार प्राप्त होने के बाद, टैग को अलग किया जाना चाहिए और डेटा (और केवल डेटा) पसंद के आपके डेटाबेस इंजन में संग्रहीत किया जाना चाहिए, जो कुछ भी हो सकता है। स्वयं एक्सएमएल नहीं है। एक्सएमएल के लिए ओवरहेड ~ 10x है जो डेटा का वर्णन कर रहा है। अपने बॉस को बताना चाहते हैं कि 100 जीबी डेटा आपके हाइपर महंगा SAN पर 1TB स्पेस क्यों ले रहा है? या एक संतृप्त नेटवर्क लिंक पर बैक अप लेने के लिए सारी रात लेना? या उत्पादन में प्रदर्शन की समस्या पैदा कर रहा है? यदि आप अब व्यर्थ टैग से डेटा का विश्लेषण नहीं करते हैं, तो आप अगले दस वर्षों के लिए परिचालन समर्थन पर समस्या और चल रहे, दैनिक समर्थन लागत को धक्का देंगे। मैला, मैला, मैला। यह व्यवसाय में ईएमसी जैसे विक्रेताओं को रखता है।

एक्सएमएल मेटाडेटा है। कुछ भी चालाक नहीं, बस एक स्कीमा वर्णनकर्ता। एक बार इसे स्थानांतरित करने और पार्स करने के बाद यह इसकी उपयोगिता खो गया है और यह केवल अव्यवस्था है जो आपके द्वारा उपयोग किए जाने वाले डेटाबेस को क्लोज़ करता है। इससे छुटकारा पाएं, जब तक कि आप कल के बिंदुहीन क्रैपी विवरण मेटाडाटा को रिकॉर्ड करने के लिए बाध्यकारी रूप से आदी न हों, कई बार संग्रहीत किया जाता है। उठो। यह ठेठ "सम्राट के नए कपड़े" सिंड्रोम है, कुछ सरल और डिस्पोजेबल द्वारा शंकु बंद कर दिया गया है। यह केवल मेटाडाटा है और इसे संग्रहीत या पूजा नहीं की जानी चाहिए, इसे पार्स करने के बाद यह जंक है। और क्या बेहतर है? इसे एक बार पर पार्स करने के लिए, या इसे प्रत्येक समय पर बेकार रूप से पार्स करने के लिए आपको इससे डेटा चाहिए? जवाब मेरे लिए स्पष्ट रूप से स्पष्ट है।

+12

यह एक अत्यधिक कठोर स्थिति है। एक्सएमएल को संग्रहीत करते समय शायद निश्चित रूप से कुछ ऐसा है जो आत्मा खोज के त्वरित क्षण को ट्रिगर करना चाहिए, निश्चित रूप से ऐसा करने के कुछ वैध कारण हैं। उदाहरण के लिए जब आपके आवेदन की एकमात्र ज़िम्मेदारी है कि एक्सएमएल को स्टोर और पुनर्प्राप्त करना (एक छवि के समान बीएलओबी के रूप में संग्रहीत किया जा रहा है)। अगर मुझे बस इतना करना है और इसे कहीं बाहर पंप करें, तो आप पागल हो जाते हैं यदि आपको लगता है कि किसी को xml पार्सिंग के कार्यों में इंजीनियरिंग का समय समर्पित करना चाहिए; संबंधपरक मॉडल बनाना; इसे मानचित्र बनाने के लिए कोड मॉडल और प्रासंगिक ORM परतें बनाना। – fostandy

+0

। । । जब तक कि व्यवसाय निर्णय लेता है कि वे xml को भेजने से पहले tweaked चाहते हैं, या वे xml के लिए आंतरिक कुछ के आधार पर सशर्त रेजिडेंट बनाना चाहते हैं, या वे आउटपुट स्वरूपों को xml से दूर स्विच करते हैं, या। । । – Nixx

संबंधित मुद्दे