यदि आपके पास किसी विकल्प के करीब कुछ है, तो पूरे डेटाबेस के लिए यूनिकोड वर्ण सेट का उपयोग करें। सामान्य तौर पर जीवन इस तरह से बहुत आसान होता है।
- ऐसी बहुत सी तृतीय पक्ष उपयोगिताएं और पुस्तकालय हैं जो NCHAR/NVARCHAR2 स्तंभों का समर्थन नहीं करते हैं या जो NCHAR/ NVARCHAR2 स्तंभों के साथ काम करना सुखद नहीं बनाते हैं। उदाहरण के लिए, जब आपका चमकदार नया रिपोर्टिंग टूल आपके NVARCHAR2 डेटा पर रिपोर्ट नहीं कर पाता है, तो यह अत्यंत कष्टप्रद होता है।
- कस्टम अनुप्रयोगों के लिए, NCHAR/NVARCHAR2 कॉलम के साथ काम करने के लिए कुछ हुप्स के माध्यम से कूदने की आवश्यकता होती है जो CHAR/VARCHAR2 यूनिकोड एन्कोडेड कॉलम के साथ काम नहीं करता है। JDBC कोड में, उदाहरण के लिए, आप लगातार Statement.setFormOfUse मेथड को कॉल करते रहेंगे। अन्य भाषाओं और ढांचे में अन्य गोचर होंगे; कुछ अपेक्षाकृत अच्छी तरह से प्रलेखित होंगे और मामूली अन्य अपेक्षाकृत अस्पष्ट होंगे।
- कई बिल्ट-इन पैकेज NVARCHAR2 के बजाय केवल VARCHAR2 को स्वीकार (या वापस) करेंगे। अंतर्निहित रूपांतरण के कारण आप अभी भी उन्हें कॉल करने में सक्षम होंगे लेकिन आप वर्ण सेट रूपांतरण समस्याओं के साथ समाप्त हो सकते हैं।
- सामान्य तौर पर, डेटाबेस के भीतर कैरेक्टर सेट रूपांतरण मुद्दों से बचने में सक्षम होना और उन मुद्दों को किनारे पर ले जाना जहां डेटाबेस वास्तव में क्लाइंट से डेटा भेज रहा है या प्राप्त कर रहा है, एप्लिकेशन को विकसित करने का काम बहुत आसान बनाता है। नेटवर्क ट्रांसमिशन से उत्पन्न होने वाले वर्ण सेट रूपांतरण मुद्दों को डीबग करने के लिए यह पर्याप्त काम है - यह पता लगाना कि कुछ डेटा दूषित हो गया है जब एक संग्रहीत प्रक्रिया एक VARCHAR2 और एक NVARCHAR2 से डेटा को जोड़ती है और परिणाम को VARCHAR2 में नेटवर्क पर भेजे जाने से पहले संग्रहीत कर सकती है कष्टदायी हो।
Oracle ने NCHAR / NVARCHAR2 डेटा प्रकारों को उन मामलों के लिए डिज़ाइन किया है जहाँ आप पुराने अनुप्रयोगों का समर्थन करने का प्रयास कर रहे हैं जो यूनिकोड का समर्थन नहीं करते हैं और नए एप्लिकेशन जो यूनिकोड का उपयोग कर रहे हैं और उन मामलों के लिए जहां कुछ यूनिकोड डेटा को एक अलग के साथ संग्रहीत करना फायदेमंद है। एन्कोडिंग (अर्थात आपके पास बड़ी मात्रा में जापानी डेटा है जिसे आप UTF-16 एन्कोडिंग का उपयोग करके UTF-8 एन्कोडिंग के बजाय NVARCHAR2 में संग्रहीत करना पसंद करेंगे)। यदि आप उन दो स्थितियों में से एक में नहीं हैं, और ऐसा नहीं लगता कि आप हैं, तो मैं हर कीमत पर NCHAR/NVARCHAR2 से बचूंगा।
आपके फ़ॉलोअप का जवाब देना
<ब्लॉककोट>हमारा एप्लिकेशन आमतौर पर Oracle डेटाबेस पर अकेला होता है और डेटा का ही ध्यान रखता है। डेटाबेस से कनेक्ट होने वाले अन्य सॉफ़्टवेयर टॉड, टोरा या SQL डेवलपर तक सीमित हैं।
आपका क्या मतलब है "डेटा का ख्याल रखता है"? मुझे आशा है कि आप यह नहीं कह रहे हैं कि आपने Oracle के वर्ण सेट रूपांतरण रूटीन को बायपास करने के लिए अपने एप्लिकेशन को कॉन्फ़िगर किया है और आप सभी वर्ण सेट रूपांतरण स्वयं करते हैं।
मैं यह भी मान रहा हूं कि आप डेटाबेस तक पहुंचने के लिए किसी प्रकार की एपीआई/लाइब्रेरी का उपयोग कर रहे हैं, भले ही वह ओसीआई हो। क्या आपने देखा है कि NCHAR/NVARCHAR2 का समर्थन करने के लिए आपको अपने आवेदन में किन परिवर्तनों की आवश्यकता होगी और क्या आप जिस API का उपयोग कर रहे हैं वह NCHAR/NVARCHAR2 का समर्थन करता है? तथ्य यह है कि आपको C++ में यूनिकोड डेटा मिल रहा है, वास्तव में यह संकेत नहीं देता है कि आपको NCHAR/NVARCHAR2 कॉलम का समर्थन करने के लिए (संभावित रूप से महत्वपूर्ण) परिवर्तन करने की आवश्यकता नहीं होगी।
<ब्लॉककोट>हम मूल विवरणों के लिए डेटाबेस के साथ संचार करने के लिए या उत्पाद के संस्करणों के बीच अपग्रेड करने के लिए SQL*Loader और SQL*Plus का भी उपयोग करते हैं। हमने NVARCHAR2 के संबंध में उन सभी सॉफ़्टवेयर के साथ किसी विशिष्ट समस्या के बारे में नहीं सुना है।
वे सभी एप्लिकेशन NCHAR/NVARCHAR2 के साथ काम करते हैं। NCHAR/NVARCHAR2 स्क्रिप्ट में कुछ अतिरिक्त जटिलताओं का परिचय देता है, खासकर यदि आप स्ट्रिंग स्थिरांक को एन्कोड करने का प्रयास कर रहे हैं जो डेटाबेस वर्ण सेट में प्रतिनिधित्व योग्य नहीं हैं। हालांकि, आप निश्चित रूप से मुद्दों के आसपास काम कर सकते हैं।
<ब्लॉककोट>हम यह भी नहीं जानते हैं कि हमारे ग्राहकों के बीच डेटाबेस व्यवस्थापक डेटाबेस पर अन्य उपकरणों का उपयोग करना चाहेंगे जो NVARCHAR2 पर डेटा का समर्थन नहीं कर सके और हम वास्तव में चिंतित नहीं हैं कि क्या उनके उपकरण बाधित हो सकते हैं, आखिरकार वे अपने काम में कुशल हैं और यदि आवश्यक हो तो अन्य उपकरण ढूंढ सकते हैं।>
जबकि मुझे यकीन है कि आपके ग्राहक आपके डेटा के साथ काम करने के वैकल्पिक तरीके खोज सकते हैं, यदि आपका एप्लिकेशन उनके एंटरप्राइज़ रिपोर्टिंग टूल या उनके एंटरप्राइज़ ईटीएल टूल या उनके द्वारा अनुभव किए जाने वाले किसी भी डेस्कटॉप टूल के साथ अच्छी तरह से नहीं चलता है, तो इसकी बहुत संभावना है कि ग्राहक अपने उपकरणों के बजाय आपके आवेदन को दोष देगा। यह शायद शो स्टॉपर नहीं होगा, लेकिन ग्राहकों को बेवजह परेशान करने का भी कोई फायदा नहीं है। यह उन्हें प्रतिस्पर्धी के उत्पाद का उपयोग करने के लिए प्रेरित नहीं कर सकता है, लेकिन यह उन्हें आपके उत्पाद को अपनाने के लिए उत्सुक नहीं करेगा।
<ब्लॉककोट>क्या हम प्रदर्शन के टूटने की भी उम्मीद कर सकते हैं यदि हमारा एप्लिकेशन (जो कि विज़ुअल सी ++ के तहत संकलित है), जो यूटीएफ -16 को स्टोर करने के लिए wchar_t का उपयोग करता है, सभी संसाधित डेटा पर शीर्ष एन्कोडिंग रूपांतरण करता है?
मुझे यकीन नहीं है कि आप किस "रूपांतरण" के बारे में बात कर रहे हैं। यह मेरे प्रारंभिक प्रश्न पर वापस आ सकता है कि क्या आप यह कह रहे हैं कि आप अपने दम पर चरित्र सेट रूपांतरण करने के लिए Oracle की NLS परत को दरकिनार कर रहे हैं।
हालाँकि, मेरी निचली पंक्ति यह है कि मुझे NCHAR/NVARCHAR2 का उपयोग करने के लिए कोई लाभ नहीं दिख रहा है जो आप वर्णन कर रहे हैं। उनका उपयोग करने के लिए संभावित डाउनसाइड्स के बहुत सारे हैं। यहां तक कि अगर आप अपनी विशेष जरूरतों के लिए अप्रासंगिक के रूप में 99% डाउनसाइड्स को खत्म कर सकते हैं, फिर भी, आप अभी भी ऐसी स्थिति का सामना कर रहे हैं जहां यह दो दृष्टिकोणों के बीच धोना है। यह देखते हुए, मैं उस दृष्टिकोण के साथ जाना चाहूंगा जो आगे जाकर लचीलेपन को अधिकतम करता है, और यह पूरे डेटाबेस को यूनिकोड (AL32UTF8 संभवतः) में परिवर्तित कर रहा है और बस इसका उपयोग कर रहा है।
