NVARCHAR का उपयोग करने का वास्तविक कारण यह है कि जब आपके पास भिन्न . है एक ही कॉलम में भाषाएं, आपको डीकोडिंग के बिना टी-एसक्यूएल में कॉलम को संबोधित करने की आवश्यकता है, आप एसएसएमएस में "मूल रूप से" डेटा देखने में सक्षम होना चाहते हैं, या आप यूनिकोड पर मानकीकृत करना चाहते हैं।
यदि आप डेटाबेस को डंब स्टोरेज के रूप में देखते हैं, तो VARCHAR (उदाहरण के लिए UTF-8) में विस्तृत स्ट्रिंग्स और विभिन्न (यहां तक कि चर-लंबाई) एन्कोडिंग को स्टोर करना पूरी तरह से संभव है। समस्या तब आती है जब आप एन्कोड और डीकोड करने का प्रयास कर रहे होते हैं, खासकर यदि कोड पेज अलग-अलग पंक्तियों के लिए अलग होता है। इसका मतलब यह भी है कि SQL सर्वर टी-एसक्यूएल के भीतर (संभावित रूप से भिन्न रूप से) एन्कोडेड कॉलम पर क्वेरी करने के प्रयोजनों के लिए आसानी से डेटा से निपटने में सक्षम नहीं होगा।
NVARCHAR का उपयोग करने से इन सब से बचा जाता है।
मैं किसी भी कॉलम के लिए NVARCHAR की सिफारिश करूंगा जिसमें उपयोगकर्ता द्वारा दर्ज किया गया डेटा होगा जो अपेक्षाकृत अप्रतिबंधित है।
मैं किसी भी कॉलम के लिए VARCHAR की सिफारिश करूंगा जो एक प्राकृतिक कुंजी है (जैसे वाहन लाइसेंस प्लेट, SSN, सीरियल नंबर, सर्विस टैग, ऑर्डर नंबर, एयरपोर्ट कॉलसाइन, आदि) जो आमतौर पर एक मानक या कानून या सम्मेलन द्वारा परिभाषित और विवश है। उपयोगकर्ता द्वारा दर्ज किए गए, और बहुत सीमित (जैसे फ़ोन नंबर) या एक कोड (सक्रिय/बंद, वाई/एन, एम/एफ, एम/एस/डी/डब्ल्यू, आदि) के लिए भी VARCHAR। उनके लिए NVARCHAR का उपयोग करने का कोई कारण नहीं है।
तो एक साधारण नियम के लिए:
VARCHAR जब विवश होने की गारंटी हैNVARCHAR अन्यथा
