मैं पेक्का के समान टिप्पणियां करता हूं, लेकिन मुझे लगता है कि हम इस पर हंस नहीं सकते हैं क्योंकि आपका कथन "यह जानकारी हालांकि काफी भिन्न हो सकती है।" इसका मतलब है कि यह सब पार्स करने और इसे डेटाबेस में प्रोजेक्ट करने की योजना बनाना यथार्थवादी नहीं है।
मैं आपके सभी सवालों का जवाब नहीं दे सकता, लेकिन मैं उनमें से कुछ का जवाब दे सकता हूं।
विशेष रूप से मैं आपको MySQL पर प्रदर्शन के बारे में नहीं बता सकता। मैंने इसे SQL सर्वर में देखा है, इसका परीक्षण किया है, और पाया है कि SQL सर्वर मेमोरी XML एक्सट्रैक्शन में करता है। बहुत धीरे-धीरे, मुझे ऐसा लग रहा था कि यह डिस्क से पढ़ रहा है, लेकिन यह थोड़ा अतिशयोक्ति है। अन्य लोग इस पर विवाद कर सकते हैं, लेकिन मुझे यही मिला।
"क्या मैसकल कॉच डीबी/तिल जैसे दस्तावेज़ उन्मुख डेटाबेस को प्रतिस्थापित कर सकता है?" यह प्रश्न थोड़ा अधिक विस्तृत है लेकिन आपके मामले में MySQL का उपयोग करने से आप इन XML विखंडू के लिए ACID अनुपालन बनाए रख सकते हैं, यह मानते हुए कि आप InnoDB का उपयोग कर रहे हैं, जो उन दस्तावेज़ उन्मुख डेटाबेस में से कुछ के लिए स्वचालित रूप से नहीं कहा जा सकता है।
"वे एक गतिशील एप्लिकेशन से बेहतर/बदतर कैसे और क्यों हैं जो विभिन्न डेटा को विशेषताओं के रूप में संग्रहीत करता है?" मुझे लगता है कि यह वास्तव में शैली का मामला है। आपको एक्सएमएल खंड दिए गए हैं जो (संभवतः) दस्तावेज हैं और MySQL उन्हें नेविगेट कर सकता है। यदि आप उन्हें वैसे ही रखते हैं-जैसे आप एक कदम बचाते हैं। उन्हें किसी और चीज़ में बदलने से क्या हासिल होगा?
MySQL डॉक्स सुझाव देते हैं कि XML फ़ाइल एक क्लॉब फ़ील्ड में जाएगी। बड़े दस्तावेज़ों पर प्रदर्शन प्रभावित हो सकता है। शायद तब आप उन उप-दस्तावेजों की पहचान करेंगे जिन्हें आप नियमित रूप से तोड़ना चाहते हैं और एक चाइल्ड टेबल में रखना चाहते हैं।
इन समान पंक्तियों के साथ, यदि ऐसे विशेष उप-दस्तावेज़ हैं जिनके बारे में आप जानना चाहते हैं, तो आप एक चाइल्ड टेबल बना सकते हैं, "HasDocs", थोड़ा पूर्व-प्रसंस्करण करें, और इसे उप-दस्तावेज़ों के नामों के साथ पॉप्युलेट करें। मायने रखता है। यह तेजी से सांख्यिकीय विश्लेषण के लिए तैयार करेगा और कुछ उप-दस्तावेज़ वाले दस्तावेज़ों को ढूंढना भी तेज़ कर देगा।
काश मैं और कह पाता, उम्मीद है कि यह मदद करता है।
