क्या डेटाबेस में लंबे तारों को स्टोर करना अच्छा है?

Question

मुझे डेटाबेस में लंबे तारों को स्टोर करने की आवश्यकता है। स्ट्रिंग 5 या 6 वाक्यों लंबी हो सकती है। क्या आपको लगता है कि यह एक अच्छी डिजाइन रणनीति है। या मुझे उस स्ट्रिंग के लिए एक आईडी स्टोर करना चाहिए और फिर किसी अन्य तालिका के साथ एक रिश्ता बनाना चाहिए जिसमें स्ट्रिंग को संग्रहीत फ़ाइल का स्थान शामिल है। क्या आप दोनों के फायदे और नुकसान दे सकते हैं।

तारों को पूर्व-प्रोसेस किया गया है और डेटाबेस में संग्रहीत किया गया है। कोई भी संशोधन पूरी स्ट्रिंग को पढ़ेगा और इसे पूरी तरह से बदल देगा। तो आप मान सकते हैं कि स्ट्रिंग अविभाज्य है।

Answer 1

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

Answer 2

पांच या छह वाक्य आधुनिक डीबीएमएस के लिए कुछ भी नहीं है! सीधे डेटाबेस में पाठ स्टोर करें।

(अन्य तकनीक आप का उल्लेख किया - एक और तालिका जो अपने आप पाठ पकड़े एक बाहरी फ़ाइल के लिए एक रेफरी है करने के लिए एक रेफरी भंडारण - बहुत अधिक उपयोग करने के लिए बोझिल हो सकता है और बहुत गरीब प्रदर्शन करना होगा।)

Answer 3

एक अलग तालिका बनाने का एकमात्र कारण यह है कि यदि उन लंबे तार कई रिकॉर्ड के लिए समान होंगे। अन्यथा यह सिर्फ एक अतिरिक्त जटिलता है जो किसी भी भुगतान की संभावना नहीं है।

Answer 4

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

Answer 5

डेटाबेस में लंबे तारों को संग्रहित करने में कोई वास्तविक समस्या नहीं है। कुछ प्रतिबंध लागू होते हैं (जैसे कि SQL सर्वर पर 8k रिकॉर्ड आकार सीमा), लेकिन फिर भी आप डेटाबेस में मनमाने ढंग से लंबाई का पाठ संग्रहीत कर सकते हैं, क्योंकि सभी उचित लोग बीओएलबी/टेक्स्ट डेटा प्रकारों को लगभग कोई ऊपरी सीमा के साथ समर्थन नहीं करते हैं।

पांच से छह वाक्यों में वास्तव में लंबा नहीं है। यदि वे एक साथ हैं और पूरी तरह से पुनर्प्राप्त और छेड़छाड़ करने के लिए हैं, तो आप आगे बढ़ सकते हैं और उचित आयामों के एक CHAR डेटा प्रकार फ़ील्ड में स्टोर कर सकते हैं।

सवाल यह है कि उन्हें अलग करना और उन्हें एक आईडी संलग्न करना केवल तभी उत्पन्न होता है जब आपका एप्लिकेशन/डेटा मॉडल सीधे इस दृष्टिकोण से लाभ उठाता है, यानी वास्तविकता में वे अलग-अलग चीजें हैं। आपके मामले में ऐसा करने का कोई कारण नहीं लगता है।

Answer 6

विशेष मामलों को छोड़कर, मैं उस क्षेत्र को छोड़ दूंगा जहां यह है।

एकमात्र अन्य विकल्प तारों को एक अलग तालिका में डालना होगा (वास्तविक तारों को वहां डालना) ... उन्हें अलग-अलग फाइलों में डालने से आपके प्रदर्शन को मार दिया जाएगा।

Answer 7

आपके द्वारा उल्लेख किए जाने वाले तार लंबे समय तक नहीं हैं।

जब आप "लंबे" तारों में लौट आए, तो मैं 32kb और ऊपर के बारे में सोच रहा था - कुछ वाक्यों < 1kb हैं - आज कुछ भी नहीं है।

आपकी चाल, आईडी को संग्रहीत करने से चीजें धीमी हो जाती हैं क्योंकि आपको अप्रत्यक्ष पहुंच बनाना पड़ता है।

एकमात्र चीज जो मैं अनुशंसा करता हूं, जब अधिकतम प्रदर्शन की आवश्यकता होती है, तो आपको केवल उन कॉलम का चयन करना चाहिए जिन्हें आपको चाहिए (चयन छोड़ें *) - इसलिए जब आवश्यक नहीं हो, तो टेक्स्ट कॉलम को छोड़ दें, क्योंकि स्ट्रिंग का परिवहन आवेदन करने के लिए सर्वर सबसे अधिक लागत है। यह एक अच्छा प्रैक्सिस है, कॉलम को छूने के लिए नहीं, विशेष रूप से जब उनमें अधिक डेटा हो सकता है)।

Answer 8

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

ऐसे कुछ मामले हैं जहां यह लागू नहीं होता है, जैसे डाटा वेयरहाउस, जिनमें बहुत कम लेनदेन होते हैं और इसलिए बिना किसी लेनदेन लॉग के जीवित रह सकते हैं।