हमारे पास एक वर्कर 2 कॉलम के साथ ओरेकल 11 जी में एक टेबल है। हम एक मालिकाना प्रोग्रामिंग भाषा का उपयोग करते हैं जहां इस कॉलम को स्ट्रिंग के रूप में परिभाषित किया जाता है। अधिकतम हम इस कॉलम में 2000 वर्ण (4000 बाइट्स) स्टोर कर सकते हैं। अब आवश्यकता ऐसी है कि कॉलम को 2000 से अधिक वर्णों (वास्तव में असीमित वर्ण) को स्टोर करने की आवश्यकता है। डीबीए को रखरखाव के कारणों के लिए बीएलओबी या लंबी डेटाटाइप पसंद नहीं है।ओरेकल 11 जी में असीमित वर्णों को कैसे स्टोर करें?
समाधान है कि मैं के बारे में सोच सकते हैं मूल तालिका से इस स्तंभ को दूर करने और इस स्तंभ के लिए एक अलग तालिका और फिर एक पंक्ति में प्रत्येक वर्ण की दुकान, असीमित वर्ण प्राप्त करने के लिए है। प्रश्नों के लिए यह तालिका मूल तालिका के साथ जुड़ जाएगी।
क्या इस समस्या का कोई बेहतर समाधान है?
अद्यतन: स्वामित्व प्रोग्रामिंग भाषा प्रकार स्ट्रिंग और ब्लॉब की चर निर्धारित करने की अनुमति देता है, वहाँ CLOB का कोई विकल्प नहीं है। मैं दिए गए प्रतिक्रियाओं को समझता हूं, लेकिन मैं डीबीए नहीं ले सकता। मैं समझता हूं कि बीएलओबी या लंबे समय से विचलन करने वाले डेवलपर्स के दुःस्वप्न होंगे, लेकिन फिर भी इसकी मदद नहीं कर सकते।
अद्यतन 2: अधिकतम मैं जरूरत है 8000 अक्षर है, तो मैं सिर्फ 3 अधिक स्तंभ जोड़ें ताकि मैं 8000 वर्ण प्राप्त करने के लिए 2000 वर्ण प्रत्येक के साथ 4 स्तंभ जाएगा कर सकते हैं। तो जब पहला कॉलम भर जाता है, तो अगले कॉलम पर मूल्यों को खाली कर दिया जाएगा और इसी तरह। क्या इस डिजाइन के किसी भी दुष्प्रभाव का असर होगा? कृपया सुझाव दे।
यह सुनिश्चित करता है कि डेलीडब्ल्यूटीएफ कहानी हमारी आंखों के सामने सामने आ रही है ... –
ठीक है, अगर आप अपने डीबीए को बताते हैं कि आप यही करने जा रहे हैं, तो मुझे यकीन है कि वे बीएलओबी पर पुनर्विचार करने के इच्छुक होंगे या लंबा इससे बचने के लिए कुछ भी :) –
कनिष्ठ डेवलपर के रूप में मेरे पास एक ही स्थिति थी और दूसरे के बाद एक मैप किए गए nvarchar पंक्तियों की एक श्रृंखला का उपयोग करने के लिए मजबूर किया गया था। सम्मिलित और अद्यतन तर्क इतना जटिल था कि एप्लिकेशन लेयर ने रखरखाव सिरदर्द को डीबीए सिरदर्द के मुकाबले बहुत खराब कर दिया था। – dkackman