2009-07-05 11 views
33

मैं वर्तमान में डेटाबेस संचालित वेबसाइट को डिजाइन करने की प्रक्रिया में हूं। मुख्य कारण सीखने के उद्देश्यों के लिए है, लेकिन मैं झूठ नहीं बोलता, वहां थोड़ी सी वैनिटी शामिल है!डेटाबेस में लेख या अन्य बड़े ग्रंथों को कैसे संग्रहीत करें

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

क्या मैं लेख HTML को सभी HTML या BBcode टैग के साथ संग्रहीत करता हूं - या यह HTML या XML दस्तावेज़ में पृष्ठ को बस बनाना बेहतर है और डीबी में इस फ़ाइल का पथ संग्रहीत करना बेहतर है?

मुझे लेखों को एक्सएमएल दस्तावेज़ के रूप में संग्रहीत करने का विचार पसंद है क्योंकि मैं आसानी से कस्टम टैग के साथ एक लेख को मार्कअप कर सकता हूं और एक्सएमएल को HTML [या वास्तव में, किसी अन्य प्रारूप] में बदलने के लिए PHP के एक्सएमएल और एक्सएसएलटी कार्यों का उपयोग कर सकता हूं। यह लेखक को लाइन/पेज ब्रेक बनाने के लिए निर्देशित करने की अनुमति देता है। इस दृष्टिकोण के लिए निश्चित रूप से अतिरिक्त कोडिंग की आवश्यकता होगी [जिसे मैं डरता नहीं हूं] लेकिन यह लेख खोजने योग्य बनाने में समस्या उत्पन्न करता है।

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

वहाँ काफी एक बहुत मैं यहाँ इस तरह के एक सरल सवाल पर लिखा है है, इसलिए मैं इसे नीचे टूट जाएगा:

1: वहाँ एक डेटाबेस में सीधे स्वरूपित पाठ की बड़ी मात्रा में भंडारण के "सर्वश्रेष्ठ" रास्ता है या
2: क्या HTML/XML/जो भी दस्तावेज़ों के रूप में उस पाठ को पथ रखना बेहतर है।

यदि 2, क्या उस पाठ को खोजने योग्य बनाने का एक शानदार तरीका है?

अपना समय :)

उत्तर

20

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

संपादित

जब तक आप केवल कीवर्ड खोज रहे हैं, db होने करना खोजें बुरी तरह धीमी गति से हो जाएगा (कभी एक मंच की खोज और यह हमेशा के लेता है?)। सूचकांक करने के लिए डेटाबेस के लिए कोई तरीका नहीं है एक

select.. where FULLTEXTFIELD like '%cookies%'. 

यह निराशा होती है एक लेख के लिए देख रहा है और खोज परिणामों अपने क्योंकि वे कीवर्ड क्षेत्र में नहीं थे देख रहे वापस नहीं करता है! Htdig आपको कुशलतापूर्वक लेख के पूर्ण पाठ को खोजने की अनुमति देता है। आपकी खोज तुरंत वापस आ जाएंगी, और लेख में हर शब्द पूरी तरह से खोजने योग्य है। मेटा टैग में कीवर्ड डालने से परिणाम पृष्ठ पर उन शर्तों की खोज अधिक हो जाएगी।

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

आपको अपने डेटाबेस से अपने सभी पृष्ठों के लिंक की सूची बनाने के लिए एक स्क्रिप्ट की आवश्यकता है। Htdig इसे स्वचालित रूप से क्रॉल करें और आपको इसके बारे में कभी भी सोचना नहीं होगा।

इसके अलावा htdig भी आपके गैर डेटाबेस पृष्ठों को क्रॉल करेगा, इसलिए आपकी पूरी साइट एक ही सरल इंटरफ़ेस के माध्यम से खोजने योग्य है।

कीवर्ड फ़ील्ड के लिए, आप में लेख की आईडी और कीवर्ड फ़ील्ड (प्रति पंक्ति 1 कीवर्ड) वाले कीवर्ड नामक एक अलग तालिका होनी चाहिए। लेकिन सादगी के लिए, डीबी में एक भी क्षेत्र होने का एक भयानक विचार नहीं है, यह कीवर्ड को बहुत आसान बना देता है यदि आप इसे एक रूप में डालते हैं।

यदि आप उस सभी परेशानी से परेशान नहीं होना चाहते हैं, तो आप Google custom search का उपयोग करने का प्रयास कर सकते हैं। यह बहुत कम काम है, लेकिन आपको कोई गारंटी नहीं है कि आपके सभी पेज अनुक्रमित होंगे।

शुभकामनाएं!

+0

वाह, धन्यवाद बायरन। आपका संपादन एक बड़ी मदद थी और एचटी: // डिग जैसा मैंने सोचा उतना ही प्रतिबंधक प्रतीत नहीं होता है। डीबी होने वाली वास्तव में छोटी साइट के लिए खोज एक बड़ा सौदा नहीं है, मुझे यकीन है कि, लेकिन मुझे उम्मीद है कि मेरी परियोजना मेरी साइट के लिए काम करती है या नहीं, मैं इसे दूसरों के लिए पुन: उपयोग कर सकता हूं और यह अच्छा होगा अगर यह स्केलेबल हो। लेकिन यह भविष्य के लिए है, वर्तमान में मुझे वास्तव में चीज़ को कोड करने की आवश्यकता है :) – Etzeitet

2

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

9

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

जैसा कि आप देखते हैं कि यह डेटाबेस में दस्तावेज़ों और पंक्तियों की मात्रा पर निर्भर करता है।

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

1

देशी xml डीबी पर एक त्वरित नज़र डालें। कई हैं, और कुछ बहुत अच्छे हैं।

खोज ईएक्सिस्ट, दस्तावेज़ एक्सडीबी, ओरेकल बर्कले।

यदि आप लगातार बना रहे हैं, अर्द्ध-संरचित पाठ को क्वेरी और अपडेट कर रहे हैं और यदि संरचना की कोई गहराई है, तो आप निश्चित रूप से कठिन तरीके से कर रहे हैं यदि आप आरडीबी पॉइंटर्स या स्टफ-इट- इन-ए-ब्लोब तकनीक - हालांकि कई बाहरी कारण हैं कि ये आर्किटेक्चर आवश्यक और सफल हो सकते हैं।

किसी डिज़ाइन पर प्रतिबद्ध होने से पहले XPath और XQuery पर थोड़ी सी पढ़ाई करें। शुरू करने के लिए यहां एक अच्छी जगह है: https://community.emc.com/community/edn/xmltech

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