वरचर और नवरचचर में क्या अंतर है?

Question

क्या यह सिर्फ nvarcharमल्टीबाइट पात्रों का समर्थन करता है? यदि ऐसा है, तो क्या वास्तव में भंडारण की चिंताओं के अलावा कोई बिंदु है, उपयोग करने के लिए varchars?

Comments

मुझे अधूरा की बात पसंद है, यह वही है जिसने मुझे पहले स्थान पर varchar & nvarchar के बीच के अंतर के बारे में खुदाई करने के लिए प्रेरित किया। SQL सर्वर db के खिलाफ हमारा जावा ऐप myBatis का उपयोग करता है, जो डिफ़ॉल्ट रूप से स्ट्रिंग को nvarchar के रूप में भेजता है (अभी भी यह सुनिश्चित नहीं है कि कैसे (या यदि यह बहुत अधिक है)। एक साधारण क्वेरी एक विशाल प्रदर्शन समस्या के रूप में दिखाई दे रही थी क्योंकि मैंने कॉलम को परिभाषित किया था कि यह varchar के रूप में चुन रहा था, नवरचर्क नहीं, और यह कॉलम पर सूचकांक की अनदेखी कर रहा था।

— शॉन

Answer 1

एक nvarcharस्तंभ किसी भी यूनिकोड डेटा को संग्रहीत कर सकता है। एक varcharस्तंभ 8-बिट कोडपेज पर प्रतिबंधित है। कुछ लोग सोचते हैं कि varcharइसका उपयोग किया जाना चाहिए क्योंकि यह कम जगह लेता है। मेरा मानना ​​है कि यह सही उत्तर नहीं है। कोडपेज असंगति एक दर्द है, और यूनिकोड कोडपेज समस्याओं का इलाज है। सस्ती डिस्क और मेमोरी के साथ, आजकल कोड पृष्ठों के साथ समय बर्बाद करने का कोई कारण नहीं है।

सभी आधुनिक ऑपरेटिंग सिस्टम और डेवलपमेंट प्लेटफॉर्म यूनिकोड का आंतरिक रूप से उपयोग करते हैं। इसके nvarcharबजाय का उपयोग करके varchar, आप डेटाबेस से पढ़ने या लिखने के लिए हर बार एन्कोडिंग रूपांतरण करने से बच सकते हैं। रूपांतरण में समय लगता है, और त्रुटियों का खतरा होता है। और रूपांतरण त्रुटियों से पुनर्प्राप्ति एक गैर-तुच्छ समस्या है।

यदि आप एक ऐसे अनुप्रयोग के साथ हस्तक्षेप कर रहे हैं जो केवल ASCII का उपयोग करता है, तो मैं अभी भी डेटाबेस में यूनिकोड का उपयोग करने की सलाह दूंगा। ओएस और डेटाबेस कोलाज एल्गोरिदम यूनिकोड के साथ बेहतर काम करेंगे। अन्य प्रणालियों के साथ इंटरफेस करने पर यूनिकोड रूपांतरण समस्याओं से बचता है। और आप भविष्य के लिए तैयारी करेंगे। और आप हमेशा यह पुष्टि कर सकते हैं कि आपके डेटा को 7-बिट एएससीआईआई तक सीमित रखा गया है, जो भी विरासत प्रणाली को बनाए रखने के लिए है, यहां तक ​​कि पूर्ण यूनिकोड भंडारण के कुछ लाभों का आनंद लेते हुए।

Comments

यह इसके लिए बड़ी जानकारी है। तो क्या मैं इसे सही ढंग से समझ रहा हूं अगर मैं यह कटौती करता हूं कि चुनाव अंततः एक हो जाता है - कौन सा संसाधन सस्ता है: प्रोसेसर + विकास ओवरहेड या भंडारण?

— मैट Cashatt

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

— जेफरी एल व्हाइटलेज

varchar सभी कोलिशन में 8 बिट कोड पेज तक ही सीमित नहीं है

— मार्टिन स्मिथ

@ मर्टिन स्मिथ - उन मामलों में, लघु लाभ जो कि varchar confers (कॉम्पैक्ट स्टोरेज) गायब हो जाता है। मुझे लगता है कि varchar इससे भी बदतर है जितना मैंने सोचा था!

— जेफरी एल व्हाइटलेज

@PeterAllenWebb - आप किसी भी यूनिकोड डेटा को "स्टोर" कर सकते हैं, क्योंकि यूटीएफ -16 में सरोगेट जोड़े को यूसीएस -2 में संग्रहीत किया जा सकता है, हालांकि वे वर्ण थे। यह डेटा भंडारण और पुनर्प्राप्ति के लिए पारदर्शी रूप से काम करेगा। अब, आप जो नहीं कर सकते हैं वह बीएमपी के बाहर विश्वसनीय केस ट्रांसफ़ॉर्मेशन और तुलनाएं प्राप्त कर सकता है, लेकिन मैंने उस बारे में कोई दावा नहीं किया है। इसलिए यदि आपके पास बहुत से डस्सेट टेक्स्ट हैं जिन पर आप प्रोसेसिंग करना चाहते हैं, तो डेटाबेस के बाहर ऐसा करना सबसे अच्छा होगा। लेकिन वहां इसे स्टोर करने के लिए यह ठीक है। (बेशक,

— वर्चर

Answer 2

varchar : चर-लंबाई, गैर-यूनिकोड वर्ण डेटा। डेटाबेस कोलाजेशन निर्धारित करता है कि कौन सा कोड पेज डेटा का उपयोग करके संग्रहीत किया गया है।

nvarchar : चर-लंबाई यूनिकोड चरित्र डेटा। तुलना के लिए डेटाबेस के टकराव पर निर्भर।

इस ज्ञान से लैस, जो भी आपके इनपुट डेटा (ASCII v। यूनिकोड) से मेल खाता है।

Comments

क्या varchar जैसा कोई प्रतिबंध यूनिकोड डेटा संग्रहीत नहीं कर सकता है? इसके सभी 1 और 0 है। मैं अपने DB से ठीक चीनी संस्करण के रूप में चीनी सामग्री को बचाने में सक्षम हूं। मैं हालांकि इसके UTF-8 को निर्दिष्ट करता हूं। फिर वह काम कैसे होता है?

— निशांत

@ निशांत देर से उत्तर : बेशक आप UTF-8 को varchar में संग्रहीत कर सकते हैं, लेकिन यह SQL सर्वर स्ट्रिंग फ़ंक्शन को तोड़ देगा। यदि आप अपने आवेदन के भीतर सभी खोज / परिवर्तन करते हैं, तो हाँ, आप ऐसा कर सकते हैं (लेकिन क्या लाभ है?)। केवल SS द्वारा समर्थित यूनिकोड एन्कोडिंग UCS-2 है (हाँ, SS2k16 से पहले UTF-16 नहीं) और इसके स्ट्रिंग फ़ंक्शंस केवल उस एन्कोडिंग के साथ काम करते हैं। BTW सूचकांकों के बारे में क्या? यदि आप मनमाना डेटा स्टोर करना चाहते हैं तो आप इसके बजाय बाइनरी का बेहतर उपयोग करेंगे।

— एड्रियानो रेपेती

हां यह सिर्फ स्ट्रिंग सर्च फंक्शन्स को तोड़ता है।

— निशांत

तो, आप जानते हैं ... यह "काम" नहीं करता है। यह एक तरह से एक floatमें intजा रहा है और जा रहा है, "अच्छी तरह से यकीन है कि दशमलव गायब हो जाते हैं।" बस नहीं है।

— user7116

Answer 3

मैं हमेशा nvarchar का उपयोग करता हूं क्योंकि यह अनुमति देता है कि मैं जो कुछ भी निर्माण कर रहा हूं वह किसी भी डेटा को झेलने के लिए है। मेरा सीएमएस सिस्टम दुर्घटना से चीनी करता है, क्योंकि मैंने नवरचेर का इस्तेमाल किया था। इन दिनों, किसी भी नए एप्लिकेशन को वास्तव में आवश्यक स्थान की मात्रा से चिंतित नहीं होना चाहिए।

Comments

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

— Frater

टैग 2k के मुंह में शब्द डालने की स्वतंत्रता लेने के लिए, मुझे लगता है कि एक अधिक सटीक कथन हो सकता है 'यह तेजी से संभावना नहीं है कि किसी भी नए एप्लिकेशन को अंतरिक्ष के बारे में अधिक चिंतित होना चाहिए क्योंकि वे अंतर्राष्ट्रीयकरण और अन्य चरित्र सेट मुद्दों के बारे में होना चाहिए'।

— कोवान

"इन दिनों, किसी भी नए एप्लिकेशन को वास्तव में आवश्यक अंतरिक्ष की मात्रा के साथ चिंतित नहीं होना चाहिए।" - जब तक आप मुफ्त क्लाउड स्टोरेज का उपयोग नहीं कर रहे हैं, जहां भुगतान की गई योजना $ में एक ठोस कूद है (AppHarbor SQL सर्वर साझा योजना देखें)।

— गैंडर्स

@ वांडर्स हॉवेल! तुम वहीं हो। सामान्यीकृत कथन केवल अस्थायी रूप से सर्वोत्तम रूप से सही होते हैं। कम्प्यूटिंग निश्चित रूप से एक झूलों और गोल चक्कर खेल है। मैं निश्चित रूप से Windows Azure CCP पर कितनी जगह का उपयोग कर रहा हूँ, से चिंतित हूँ। कहा कि मैं नवरचचर पर "कभी नहीं" का उपयोग करूंगा। Ooo क्या मैंने सिर्फ खुद का विरोध किया?

— जिस्म r

@rism, मेरा मानना ​​है कि आपने "never"कम से कम तकनीकी रूप से अपने उद्धरणों के उपयोग के साथ विरोधाभास के किसी भी जोखिम को हटा दिया है ।

— स्मंदोली

Answer 4

यह इस बात पर निर्भर करता है कि ओरेकल कैसे स्थापित किया गया था। स्थापना प्रक्रिया के दौरान, NLS_CHARACTERSET विकल्प सेट किया गया है। आप इसे क्वेरी से ढूंढने में सक्षम हो सकते हैं SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET'।

यदि आपका NLS_CHARACTERSET UTF8 की तरह एक यूनिकोड एन्कोडिंग है, तो बढ़िया। VARCHAR और NVARCHAR का उपयोग करना बहुत समान हैं। अभी पढ़ना बंद करो, बस इसके लिए जाओ। अन्यथा, या यदि आपका Oracle वर्ण सेट पर कोई नियंत्रण नहीं है, तो पढ़ें।

VARCHAR - डेटा NLS_CHARACTERSET एन्कोडिंग में संग्रहीत है। यदि एक ही सर्वर पर अन्य डेटाबेस इंस्टेंसेस हैं, तो आप उनके द्वारा प्रतिबंधित हो सकते हैं; और इसके विपरीत, चूंकि आपको सेटिंग साझा करनी होगी। ऐसा क्षेत्र किसी भी डेटा को संग्रहीत कर सकता है जिसे उस वर्ण सेट का उपयोग करके एन्कोड किया जा सकता है, और कुछ नहीं । इसलिए उदाहरण के लिए यदि चरित्र सेट MS-1252 है, तो आप केवल अंग्रेजी अक्षरों, कुछ मुट्ठी भर अक्षरों और कुछ अन्य (जैसे € और -) जैसे पात्रों को संग्रहीत कर सकते हैं। आपका आवेदन केवल कुछ ही स्थानों के लिए उपयोगी होगा, दुनिया में कहीं और संचालित करने में असमर्थ। इसी वजह से इसे ए बैड आइडिया माना जाता है।

NVARCHAR - डेटा को एक यूनिकोड एन्कोडिंग में संग्रहीत किया जाता है। हर भाषा का समर्थन किया है। एक अच्छा विचार।

भंडारण स्थान के बारे में क्या? VARCHAR आम तौर पर कुशल है, क्योंकि वर्ण सेट / एन्कोडिंग एक विशिष्ट स्थान के लिए कस्टम-डिज़ाइन किया गया था। NVARCHAR क्षेत्र या तो UTF-8 या UTF-16 एन्कोडिंग में स्टोर करते हैं, जो कि NLS के आधार पर विडंबनापूर्ण रूप से पर्याप्त है। यूटीएफ -8 "पश्चिमी" भाषाओं के लिए बहुत कुशल है, जबकि अभी भी एशियाई भाषाओं का समर्थन कर रहा है। UTF-16 एशियाई भाषाओं के लिए बहुत कुशल है, जबकि अभी भी "पश्चिमी" भाषाओं का समर्थन कर रहा है। यदि संग्रहण स्थान के बारे में चिंतित हैं, तो Oracle के लिए UTF-8 या UTF-16 का उपयोग करने के लिए उपयुक्त के रूप में NLS सेटिंग चुनें।

प्रसंस्करण गति के बारे में क्या? अधिकांश नए कोडिंग प्लेटफ़ॉर्म यूनिकोड का उपयोग मूल रूप से करते हैं (Java, .NET, यहां तक ​​कि C ++ std :: wstring from years!!) इसलिए यदि डेटाबेस फ़ील्ड VARCHAR है तो यह Oracle को प्रत्येक पढ़ने या लिखने पर वर्ण सेट के बीच परिवर्तित करने के लिए मजबूर करता है, अच्छा नहीं। NVARCHAR का उपयोग रूपांतरण से बचता है।

नीचे पंक्ति: NVARCHAR का उपयोग करें! यह सीमाओं और निर्भरता से बचता है, भंडारण स्थान के लिए ठीक है, और आमतौर पर प्रदर्शन के लिए भी सबसे अच्छा है।

Comments

यह वास्तव में एक अच्छा जवाब है, सिवाय इसके कि सवाल sql-server के बारे में है।

— उत्तेजित करता है

Answer 5

Nvarchar यूनिकोड के रूप में डेटा को संग्रहीत करता है, इसलिए, यदि आप एक डेटा कॉलम में बहुभाषी डेटा (एक से अधिक भाषा) संग्रहीत करने जा रहे हैं, तो आपको N संस्करण की आवश्यकता होगी।

Answer 6

मेरे दो सेंट

1. सही डेटाटाइप का उपयोग न करने पर अनुक्रमणिका विफल हो सकती है:
   SQL सर्वर में: जब आपके पास VARCHAR स्तंभ पर एक सूचकांक होता है और इसे एक यूनिकोड स्ट्रिंग प्रस्तुत करता है, तो SQL सर्वर सूचकांक का उपयोग नहीं करता है। यही बात तब होती है जब आप BigInt को SmallInt वाले अनुक्रमित-कॉलम में प्रस्तुत करते हैं। भले ही BigInt एक SmallInt होने के लिए काफी छोटा है, लेकिन SQL सर्वर इंडेक्स का उपयोग करने में सक्षम नहीं है। आपके आस-पास का दूसरा तरीका यह समस्या नहीं है (जब एक अनुक्रमित BigInt ot NVARCHAR कॉलम में SmallInt या Ansi-Code प्रदान करता है)।

2. डेटाबैट अलग-अलग डीबीएमएस (डेटाबेस मैनेजमेंट सिस्टम) के बीच भिन्न हो सकते हैं: यह
   जान लें कि हर डेटाबेस में थोड़ा अलग डेटाटिप्स होता है और VARCHAR का मतलब हर जगह समान नहीं होता है। जबकि SQL सर्वर में VARCHAR और NVARCHAR होते हैं, अपाचे / डर्बी डेटाबेस में केवल VARCHAR होता है और वहां VARCHAR यूनिकोड में होता है।

Comments

लेकिन निश्चित रूप से यदि आप अपने कोड को ठीक से लिख रहे हैं (अर्थात पैरामीटर किए गए प्रश्नों आदि का उपयोग करके) तो बिंदु 1 एक जोखिम से कम है।

— पॉल

Answer 7

मुख्य रूप से nvarchar यूनिकोड वर्ण और varchar संग्रहीत करता है स्टोर गैर-यूनिकोड वर्ण संग्रहीत करता है।

"यूनिकोड्स" का अर्थ है 16-बिट चरित्र एन्कोडिंग योजना जो अरबी, हिब्रू, चीनी, जापानी जैसी कई अन्य भाषाओं के पात्रों को एकल वर्ण सेट में एन्कोड करने की अनुमति देती है।

इसका मतलब है कि यूनिकोड स्टोर करने के लिए प्रति चरित्र 2 बाइट्स का उपयोग कर रहा है और नॉनकोड्स स्टोर करने के लिए केवल एक बाइट प्रति वर्ण का उपयोग करता है। जिसका अर्थ है कि यूनिकोड को गैर-यूनिकोड की तुलना में स्टोर करने के लिए दोहरी क्षमता की आवश्यकता होती है।

Answer 8

आप सही हे। एकल-बाइट वर्ण डेटा संग्रहीत nvarcharकरते समय यूनिकोड डेटा varcharसंग्रहीत करता है। भंडारण मतभेदों की तुलना में अन्य ( nvarcharकी आवश्यकता के रूप में दो बार भंडारण स्थान varchar), जो आप पहले से ही उल्लेख किया है,, पसंद करते हैं के लिए मुख्य कारण nvarcharअधिक varchar(अन्य भाषाओं में यानी भंडारण तार) अंतर्राष्ट्रीयकरण किया जाएगा।

Answer 9

मैं कहूंगा, यह निर्भर करता है।

यदि आप एक डेस्कटॉप एप्लिकेशन विकसित करते हैं, जहां ओएस यूनिकोड (सभी वर्तमान विंडोज सिस्टम की तरह) में काम करता है और भाषा यूनिकोड का समर्थन करती है (डिफ़ॉल्ट स्ट्रिंग्स यूनिकोड हैं, जैसे जावा या सी # में), तो nvarchar जाएं।

यदि आप एक वेब एप्लिकेशन विकसित करते हैं, जहां स्ट्रिंग्स UTF-8 के रूप में आते हैं, और भाषा PHP है, जो अभी भी यूनिकोड को मूल रूप से (संस्करण 5.x में) का समर्थन नहीं करती है, तो varchar शायद एक बेहतर विकल्प होगा।

Answer 10

हालाँकि NVARCHAR, यूनिकोड को संग्रहीत करता है, आपको समतलीकरण की सहायता से विचार करना चाहिए जिसे आप VARCHARअपनी स्थानीय भाषाओं के डेटा का उपयोग और सहेज सकते हैं।

बस निम्नलिखित परिदृश्य की कल्पना करें।

आपके DB का टकराव फ़ारसी है और आप 'علی' (अली का फ़ारसी लेखन) जैसे मूल्य को बचाते हैं VARCHAR(10) डेटाटाइप । कोई समस्या नहीं है और DBMS इसे स्टोर करने के लिए केवल तीन बाइट्स का उपयोग करता है।

हालाँकि, यदि आप अपने डेटा को किसी अन्य डेटाबेस में स्थानांतरित करना चाहते हैं और सही परिणाम देखते हैं तो आपके गंतव्य डेटाबेस में लक्ष्य के समान ही समतलीकरण होना चाहिए जो इस उदाहरण में फ़ारसी है।

यदि आपका लक्ष्य टकराना अलग है, तो आप लक्ष्य डेटाबेस में कुछ प्रश्न चिह्न (?) देखते हैं।

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

मेरा मानना ​​है कि डिजाइन अलग हो सकता है। यह उस वातावरण पर निर्भर करता है जिस पर आप काम करते हैं।

Answer 11

मुझे जवाबों पर एक नज़र थी और कई लोग इसे इस्तेमाल करने की सलाह देते दिख रहे nvarcharहैं varchar, क्योंकि अंतरिक्ष में अब कोई समस्या नहीं है, इसलिए थोड़ा अतिरिक्त भंडारण के लिए यूनिकोड को सक्षम करने में कोई बुराई नहीं है। खैर, यह हमेशा सच नहीं होता है जब आप अपने कॉलम पर एक इंडेक्स लागू करना चाहते हैं। SQL सर्वर आपके द्वारा अनुक्रमित किए जाने वाले फ़ील्ड के आकार पर 900 बाइट्स की सीमा है। तो अगर आपके पास एक है varchar(900)तो आप इसे अभी भी अनुक्रमित कर सकते हैं, लेकिन नहीं varchar(901)। के साथ nvarchar, वर्णों की संख्या आधी हो जाती है, इसलिए आप इसे अनुक्रमित कर सकते हैं nvarchar(450)। इसलिए यदि आप आश्वस्त हैं कि आपको इसकी आवश्यकता नहीं है nvarchar, तो मैं इसका उपयोग करने की सलाह नहीं देता।

सामान्य तौर पर, डेटाबेस में, मुझे आपके द्वारा आवश्यक आकार से चिपके रहने की सलाह दी जाती है, क्योंकि आप हमेशा विस्तार कर सकते हैं। उदाहरण के लिए, काम पर एक सहयोगी ने एक बार सोचा था कि nvarchar(max)एक स्तंभ के लिए उपयोग करने में कोई बुराई नहीं है , क्योंकि हमें भंडारण में कोई समस्या नहीं है। बाद में, जब हमने इस कॉलम पर एक इंडेक्स लागू करने का प्रयास किया, तो SQL सर्वर ने इसे अस्वीकार कर दिया। यदि, हालांकि, उसने शुरुआत भी की varchar(5), तो हम इसे बाद में विस्तारित कर सकते थे कि हमें इस तरह की समस्या के बिना क्या चाहिए जो हमें इस समस्या को ठीक करने के लिए एक क्षेत्र प्रवास योजना बनाने की आवश्यकता होगी।

Answer 12

nVarchar आपको यूनिकोड वर्णों को संग्रहीत करने में मदद करेगा। यदि आप स्थानीय डेटा संग्रहीत करना चाहते हैं तो यह जाने का तरीका है।

Answer 13

यदि किसी पात्र को संग्रहीत करने के लिए एकल बाइट का उपयोग किया जाता है, तो 256 संभावित संयोजन होते हैं, और इस तरह आप 256 विभिन्न वर्णों को बचा सकते हैं। Collation वह पैटर्न है जो वर्णों और नियमों को परिभाषित करता है जिसके द्वारा उनकी तुलना की जाती है और क्रमबद्ध किया जाता है।

1252, जो कि लैटिन 1 (ANSI) है, सबसे आम है। एकल-बाइट वर्ण सेट भी कई भाषाओं द्वारा उपयोग किए जाने वाले सभी वर्णों को संग्रहीत करने के लिए अपर्याप्त हैं। उदाहरण के लिए, कुछ एशियाई भाषाओं में हजारों वर्ण हैं, इसलिए उन्हें प्रति वर्ण दो बाइट्स का उपयोग करना चाहिए।

यूनिकोड मानक

जब नेटवर्क में कई कोड पेज का उपयोग करने वाले सिस्टम का उपयोग किया जाता है, तो संचार का प्रबंधन करना मुश्किल हो जाता है। चीजों को मानकीकृत करने के लिए, आईएसओ और यूनिकोड संघ ने यूनिकोड की शुरुआत की । यूनिकोड प्रत्येक वर्ण को संग्रहीत करने के लिए दो बाइट्स का उपयोग करता है। यह 65,536 विभिन्न वर्णों को परिभाषित किया जा सकता है, इसलिए लगभग सभी पात्रों को यूनिकोड के साथ कवर किया जा सकता है। यदि दो कंप्यूटर यूनिकोड का उपयोग करते हैं, तो हर प्रतीक का उसी तरह से प्रतिनिधित्व किया जाएगा और किसी भी रूपांतरण की आवश्यकता नहीं है - यह यूनिकोड के पीछे का विचार है।

SQL सर्वर में वर्ण डेटाटाइप्स की दो श्रेणियां हैं:

• गैर-यूनिकोड (चार, चरक और पाठ)
• यूनिकोड (nchar, nvarchar, और ntext)

यदि हमें कई देशों के चरित्र डेटा को बचाने की आवश्यकता है, तो हमेशा यूनिकोड का उपयोग करें।

Answer 14

मुझे यहां कहना है (मुझे एहसास है कि मैं शायद खुद को एक स्लेटिंग के लिए खोलने जा रहा हूं!), लेकिन निश्चित रूप से केवल एक ही समय है जब NVARCHARवास्तव में अधिक उपयोगी है ( अधिक वहां नोटिस !)।VARCHAR जब सभी पर सभी टकराव होते हैं। निर्भर प्रणालियों और डेटाबेस के भीतर ही समान हैं ...? यदि नहीं तो टक्कर रूपांतरण वैसे भी होता है और इसलिए VARCHARजैसा होता है वैसा ही व्यवहार्य होता है NVARCHAR।

इसे जोड़ने के लिए, कुछ डेटाबेस सिस्टम, जैसे कि SQL सर्वर (2012 से पहले) में लगभग एक पृष्ठ का आकार होता है। 8K। इसलिए, यदि आप एक तरह कुछ में आयोजित नहीं खोजा डेटा भंडारण पर देख रहे हैं TEXTयाNTEXT फ़ील्ड फ़ील्डVARCHAR पूर्ण 8k का स्थान NVARCHARप्रदान करता है, जबकि केवल 4k (डबल बाइट्स, डबल स्पेस) प्रदान करता है।

मुझे लगता है, संक्षेप में, या तो उपयोग पर निर्भर है:

• परियोजना या संदर्भ
• भूमिकारूप व्यवस्था
• डेटाबेस सिस्टम

Answer 15

Sql सर्वर VARCHAR और NVARCHAR डेटा प्रकार के बीच अंतर का पालन करें । यहाँ आप बहुत वर्णनात्मक तरीके से देख सकते हैं।

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

Comments

यह एक बहुत ही उपयोगी लिंक है, लेकिन आपका जवाब इससे बहुत अधिक नहीं है: एक लिंक।

— रबडकॉक

ckuhn203, मैं आपको यह देखने के लिए नहीं कह रहा हूं

— प्रदीप केशरवानी

Answer 16

के बीच मुख्य अंतर Varchar(n)और nvarchar(n)है:

Varchar(चर-लंबाई, गैर-यूनिकोड चरित्र डेटा) का आकार 8000 तक है। 1. यह एक चर लंबाई डेटा प्रकार है

2. गैर-यूनिकोड वर्णों को संग्रहीत करने के लिए उपयोग किया जाता है

3. प्रत्येक वर्ण के लिए स्थान की 1 बाइट पर कब्जा करता है

Nvarchar: चर-लंबाई यूनिकोड चरित्र डेटा।

1. यह एक चर-लंबाई डेटा प्रकार है

2. यूनिकोड वर्णों को संगृहीत करना।

3. डेटा को यूनिकोड एन्कोडिंग में संग्रहीत किया जाता है। हर भाषा का समर्थन किया है। (उदाहरण के लिए अरबी, जर्मन, हिंदी, इत्यादि)

Answer 17

जेफरी एल व्हिटलेज ~ 47000 प्रतिष्ठा स्कोर के साथ nvarchar के उपयोग की सिफारिश करता है

~ 33200 प्रतिष्ठा स्कोर के साथ सोलोमन रुट्ज़की की सिफारिश: हमेशा NVARCHAR का उपयोग न करें। यह एक बहुत ही खतरनाक है, और अक्सर महंगा, दृष्टिकोण / दृष्टिकोण है।

Varchar और nvarchar SQL Server डेटा प्रकारों के बीच मुख्य प्रदर्शन अंतर क्या हैं?

https://www.sqlservercentral.com/articles/disk-is-cheap-orly-4

इतनी उच्च प्रतिष्ठा के दोनों व्यक्ति, एक लर्निंग एसक्यूएल सर्वर डेटाबेस डेवलपर क्या चुनते हैं?

यदि आप विकल्पों में सुसंगत नहीं हैं, तो प्रदर्शन के मुद्दों के बारे में जवाब और टिप्पणियों में कई चेतावनियाँ हैं।

प्रदर्शन के लिए टिप्पणियाँ / con nvarchar हैं।

प्रदर्शन के लिए टिप्पणियाँ प्रो / चोर varchar हैं।

मुझे कई स्तंभों वाली एक मेज के लिए एक विशेष आवश्यकता है, जो अपने आप में शायद असामान्य है?

मैं SQL * सर्वर 2012 के 8060 बाइट टेबल रिकॉर्ड आकार सीमा के करीब जाने से बचने के लिए varchar चुन रहा हूं।

मेरे लिए nvarchar का उपयोग, इस 8060 बाइट सीमा से अधिक हो जाता है।

मैं यह भी सोच रहा हूं कि मुझे संबंधित कोड टेबल के डेटा प्रकारों को प्राथमिक केंद्रीय तालिका के डेटा प्रकारों से मेल खाना चाहिए।

मैंने पिछले अनुभवी डेटाबेस डेवलपर्स द्वारा काम के इस स्थान पर, दक्षिण ऑस्ट्रेलियाई सरकार के वर्कशीट कॉलम का उपयोग देखा है, जहां टेबल पंक्ति की गिनती कई लाख या अधिक होने वाली है (और बहुत कम nvarchar कॉलम, यदि कोई हो, तो इन बहुत बड़े में तालिकाएँ), इसलिए शायद अपेक्षित डेटा पंक्ति वॉल्यूम इस निर्णय का हिस्सा बन जाए।

Answer 18

nvarcharvarcharहमारे कोड को त्रुटि मुक्त बनाने के लिए उपयोग करने के लिए सुरक्षित है (प्रकार बेमेल) क्योंकि nvarcharयूनिकोड वर्णों को भी अनुमति देता है। जब हम whereSQL सर्वर क्वेरी में स्थिति का उपयोग करते हैं और यदि हम =ऑपरेटर का उपयोग कर रहे हैं , तो यह कुछ बार त्रुटि फेंक देगा। इसका संभावित कारण यह है कि हमारे मैपिंग कॉलम में अंतर किया जाएगा varchar। अगर हम इसे nvarcharइस समस्या में परिभाषित करते हैं तो ऐसा नहीं होता है। फिर भी हम varcharइस मुद्दे से चिपके रहते हैं और इस मुद्दे से बचते हैं कि हम बेहतर LIKEशब्द का इस्तेमाल करें =।