1. घर
  2. सवाल और जवाब
  3. वाराचर पूरी तरह से 1 99 0 की तरह है?

वाराचर पूरी तरह से 1 99 0 की तरह है?

2008-11-23 21 views
47
  1. VARCHAR यूनिकोड वर्णों को संग्रहीत नहीं करता है।
  2. NVARCHAR यूनिकोड वर्णों को स्टोर करता है।
  3. आज के अनुप्रयोग हमेशा यूनिकोड संगत होना चाहिए।
  4. NVARCHAR इसे स्टोर करने के लिए स्थान की मात्रा से दोगुना लेता है।
  5. प्वाइंट 4 कोई फर्क नहीं पड़ता क्योंकि भंडारण स्थान बेहद सस्ती है।

एर्गो: आज SQL सर्वर डेटाबेस को डिज़ाइन करते समय, किसी को हमेशा NVARCHAR का उपयोग करना चाहिए।वाराचर पूरी तरह से 1 99 0 की तरह है?

क्या यह ध्वनि तर्क है? क्या कोई भी परिसर से असहमत है? क्या आज NVARCHAR पर VARCHAR चुनने के कोई कारण हैं?

स्रोत

2008-11-23 Edward Tanguay

+0

इसे भी देखें http://stackoverflow.com/q/35366/27535 – gbn

+0

यह _not_ ध्वनि तर्क है, मुख्य रूप से अमान्य परिसर के कारण। आइटम 3 एक बयान का बहुत व्यापक है। आइटम 4 आंशिक रूप से अप्रचलित है क्योंकि SQL Server 2008 ने पृष्ठ और पंक्ति संपीड़न प्रस्तुत किया है, और 2008 आर 2 जोड़ा गया है (दृश्यों के पीछे स्वचालित/पीछे) यूनिकोड संपीड़न (लेकिन संपीड़न केवल एंटरप्राइज़ संस्करण में उपलब्ध है)। आइटम 5 बेतुका गलत है। विवरण के लिए कृपया मेरा उत्तर यहां देखें: http://stackoverflow.com/a/32871477/577765 –

उत्तर

48

आप डेटाटाइप से डेटा के साथ मिलान करते हैं जो कॉलम में संग्रहीत किया जाएगा। इसी तरह के तर्क से आप कह सकते हैं कि क्यों NVARCHAR कॉलम में सभी डेटा स्टोर नहीं करते हैं, क्योंकि संख्याओं और तिथियों को अंकों के तारों के रूप में दर्शाया जा सकता है।

यदि कॉलम में संग्रहीत डेटा के लिए सबसे अच्छा मिलान VARCHAR है, तो इसका उपयोग करें।

स्रोत

2008-11-23 06:54:08 dkretz

1

मैं इस विषय पर कोई विशेषज्ञ नहीं हूं। लेकिन किसी भी कारण से आप छोटी जगह और यूनिकोड के संयोजन के लिए यूटीएफ -8 का उपयोग नहीं कर सके?

स्रोत

2008-11-23 05:49:02

+0

माइक्रोसॉफ्ट एसक्यूएल सर्वर (कम से कम 2000 और 2005) यूटीएफ -8 में चरित्र डेटा संग्रहित करने का समर्थन नहीं करता है। –

+0

क्या यूटीएफ -8 बहुत ज्यादा एएससीआईआई नहीं है? –

+0

केवल कोड बिंदुओं के लिए जो ASCII रेंज के भीतर आते हैं - अन्यथा यह पूरी तरह अलग है –

27

मैं कहूंगा कि अभी भी nvarchar का उपयोग करने के वैध कारण नहीं हैं।

  • संग्रहण स्थान इस तरह के एक साझा मेजबान पर के रूप में, एक प्रीमियम पर है या डेटाबेस वास्तव में बहुत बड़ा है।
  • प्रदर्शन महत्वपूर्ण है।
  • ब्राउनफील्ड विकास (यानी डेटाबेस में मौजूदा सारणी हैं जो वर्चर का उपयोग करती हैं)।
  • आप एक और पुरानी प्रणाली के साथ एकीकृत कर रहे हैं जो केवल एक बाइट वर्ण और/या वर्कर को समझता है।

हालांकि नए विकास शायद nvarchar esp का उपयोग करना चाहिए। चूंकि 64-बिट सिस्टम मानक बन रहे हैं। इसके अलावा, कंपनियां (यहां तक ​​कि छोटे भी) अब अधिक सामान्य हैं।

स्रोत

2008-11-23 06:15:58

+0

64 बिट को nvarchar के साथ क्या करना है? – Jeremy

+2

डबल-वाइड वर्ण दो गुना अधिक स्मृति लेते हैं, लेकिन यह 64-बिट सिस्टम पर चिंता का बहुत कम है, क्योंकि वे 32-बिट सिस्टम की तुलना में अधिक रैम को संबोधित कर सकते हैं। 32-बिट विंडोज़ पर 32-बिट एसक्यूएल सर्वर (अभी भी '08 में काफी आम है) केवल 2 जीबी रैम का उपयोग कर सकता है (डब्ल्यू/ओ हुप्स के माध्यम से कूद रहा है) –

2

संग्रहण ऐतिहासिक रूप से कहीं भी महंगा है, लेकिन फिर भी यदि आप किसी दिए गए हार्ड ड्राइव पर दो गुना अधिक डेटा स्टोर कर सकते हैं, तो यह आकर्षक है, है ना?

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

स्रोत

2008-11-23 06:24:03

3

आपका पॉइंट 3 अमान्य है। सिस्टम जो केवल एक देश के उपयोग के लिए डिज़ाइन किए गए हैं, को यूनिकोड के बारे में चिंता करने की ज़रूरत नहीं है, और कुछ भाषाओं/उत्पादों का उपयोग यूनिकोड को या तो आंशिक रूप से समर्थन नहीं करता है। उदाहरण के लिए, TurboTax केवल यूएस के लिए है (और फ्रेंच के साथ कनाडाई संस्करण के साथ भी अभी भी लैटिन -1 है), इसलिए उन्हें यूनिकोड के बारे में चिंता करने की आवश्यकता नहीं होगी और शायद इसका समर्थन नहीं है (मैं नहीं करता पता है कि वे करते हैं या नहीं, लेकिन अगर वे करते हैं, तो यह सिर्फ एक उदाहरण है)।

"आज के अनुप्रयोग हमेशा यूनिकोड संगत होना चाहिए।आज की अनुप्रयोगों हमेशा यूनिकोड संगत होना चाहिए कुछ भी नहीं विशेष जरूरतों यूनिकोड ठीक से संभाल होने के लिये हैं, और एक पहले से मौजूदा codebase या आवेदन के किसी भी अन्य टुकड़ा की जरूरत नहीं है: "

शायद अधिक मान्य व्यक्त जैसा है" विशेष रूप से अद्यतन करने की यह "

स्रोत

2008-11-23 06:24:52 MetroidFan2002

+1

मुझे लगता है कि मैं हमेशा यूनिकोड के संभावित अपग्रेड के दर्द को और अधिक भार दूंगा शायद अधिक भंडारण स्थान का उपयोग करने के दर्द से। –

+0

@ एडवर्ड, यह एक तकनीकी निर्णय के बजाय एक व्यावसायिक निर्णय होगा। हमारी कंपनी (और यह बड़ी है) अभी भी कुछ अंग्रेजी-केवल डेटाबेस-अनुप्रयोगों का उपयोग करती है क्योंकि यह हमारा वांछित बाजार है। – paxdiablo

+1

गैर-अंग्रेजी भाषी देश के सदस्य के रूप में (हां वहां उनमें से कुछ हैं), जहां भाषा में डायक्रिटिक्स शामिल हैं, मैं कह सकता हूं कि अनुप्रयोग यूनिकोड संगत होना चाहिए। – PiRX

39

प्वाइंट 4 कोई फर्क नहीं पड़ता क्योंकि भंडारण स्थान अत्यंत सस्ती है समर्थन करने के लिए

यह सिर्फ भंडारण, लेकिन बैंडविड्थ नहीं है -। सीपी आप, स्मृति, बैकअप, वसूली, स्थानांतरण। संरक्षण।

स्रोत

2008-11-23 06:48:43 Sam

+0

मेरे उत्तर में यहां दिए गए लिंक: http://stackoverflow.com/questions/35366/varchar-vs-nvarchar-performance/198753#198753 – gbn

+0

किसी डेटाबेस में "NVARCHAR" के रूप में संग्रहण का अर्थ यह नहीं है कि डेटा भेजा जाता है " तार पर "यूसीएस -2 एन्कोडेड यूनिकोड के रूप में। यह तार पर जा सकता है और यूटीएफ -8 के रूप में एप्लिकेशन मेमोरी में प्रतिनिधित्व किया जा सकता है ... जो "हर समय एक-बाइट प्रति char" है। –

2

क्या आपके डेटाबेस सर्वर के लिए एन्कोडिंग के रूप में यूटीएफ -8 का उपयोग करने का कोई तरीका है? इसके बाद आपको अधिकतर एएससीआईआई लोड के लिए कम भंडारण के लाभ मिलते हैं, और यूनिकोड की सीमा में कुछ भी स्टोर करने की क्षमता होती है ताकि विस्तार संभव हो।

मैं यूटीएफ -8 को VARCHAR एसक्यूएल प्रकार के लिए एन्कोडिंग के रूप में समर्थन देने के लिए अपने डेटाबेस विक्रेता से पूछूंगा। मुझे नहीं पता कि अन्य डीबी सर्वर इसे कैसे करते हैं, लेकिन मुझे पता है कि आप कम से कम MySQL और PostgreSQL में VARCHAR और TEXT फ़ील्ड में यूटीएफ -8 का उपयोग कर सकते हैं।

कि सभी हालांकि कहा गया है, लिए एकमात्र कारण एक UTF-16 एन्कोडेड क्षेत्र का उपयोग नहीं आप अनुप्रयोगों जिस पर UTF-16 के इनपुट टूट जाएगा के साथ बातचीत करने के लिए है, तो है। यह सबसे विरासत अनुप्रयोग होगा जो ASCII या ISO-8815 टेक्स्ट एन्कोडिंग को संभालने के लिए डिज़ाइन किए गए थे, जो यूटीएफ -8 को प्रोसेस करना बेहतर होगा।

स्रोत

2008-11-23 07:08:59

+0

एमएस एसक्यूएल सर्वर यूटीएफ 8 का समर्थन नहीं करता है। यह यूसीएस -2 का उपयोग करता है, जो मूल बहुभाषी विमान (बीएमपी) के पात्रों के लिए लगभग यूटीएफ -16 के बराबर है। मुझे नहीं पता कि यूटीएफ -8 का समर्थन करने के लिए एक हैक मौजूद है, लेकिन मुझे शक है। – Triynko

+0

उस स्थिति में, यह एक चरित्र सेट कनवर्टर के साथ डेटाबेस तक पहुंच को लपेटने के लिए सबसे अच्छा होगा, ताकि यह यूटीएफ -8 मानों को एप्लिकेशन में वापस कर दे और डेटाबेस में यूटीएफ -16 मान भेज सके। कम से कम, मैं यही करूँगा अगर मैं एक सिस्टम के साथ काम कर रहा था जहां मुझे चरित्र एन्कोडिंग के बारे में चिंता करने की ज़रूरत थी। यदि आपको चरित्र एन्कोडिंग के बारे में चिंता करने की ज़रूरत नहीं है (उदाहरण के लिए, पायथन 3 या कुछ जो इसकी देखभाल करता है तो पारदर्शी रूप से) तो मुझे लगता है कि यह वास्तव में कोई फर्क नहीं पड़ता ... –

5

जैसा कि अन्य ने बताया है, यह केवल भंडारण की लागत नहीं है।

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

तो यह आपको हर मोर्चे पर प्रदर्शन खो देता है। यदि आप वास्तव में परवाह नहीं करते हैं (या प्रदर्शन को माप सकते हैं और इसके साथ खुश हैं), तो यह ठीक है। लेकिन यदि आपके पास यूनिकोड वर्णों को स्टोर करने की वास्तविक आवश्यकता है, तो निश्चित रूप से, NVARCHAR का उपयोग करें।

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

स्रोत

2008-11-23 07:29:25 MarkR

11

मेरा मानना ​​है कि nvarchars की तुलना वर्चर्स की तुलना में अधिक महंगा है, इसलिए यह उन जगहों पर पूरी तरह वैध है और यहां तक ​​कि उन जगहों पर भी पसंदीदा है जहां आपको वास्तव में यूनिकोड क्षमताओं की आवश्यकता नहीं है, यानी, कुछ आंतरिक आईडी के लिए।

और भंडारण लागत अभी भी मायने रखती है। यदि आपके पास अरबों पंक्तियां हैं तो उन "छोटे" अंतर बहुत तेज़ हो जाते हैं।

स्रोत

2008-11-23 07:32:56 PiRX

5

इस तरह के प्रश्नों का हमेशा एक ही जवाब है: यह पर निर्भर करता है। कोई जादुई नियम नहीं है कि आपको अंधेरे का पालन करना चाहिए। यहां तक ​​कि आधुनिक प्रोग्रामिंग भाषाओं में गोटो का उपयोग उचित भी किया जा सकता है: Is it ever advantageous to use 'goto' in a language that supports loops and functions? If so, why?

तो जवाब है: अपने सिर का उपयोग करें और विशेष स्थिति के बारे में सोचें। इस विशेष उदाहरण में ध्यान रखें कि यदि आप अपनी आवश्यकताओं को बदल देते हैं तो आप हमेशा डेटाबेस में वर्चार से nvarchar में परिवर्तित कर सकते हैं।

स्रोत

2008-11-23 08:44:50 Brannon

4

मैंने देखा है nvarchar स्तंभ दो कारणों के लिए varchar में बदला:

  1. आवेदन MSSQL एक्सप्रेस संस्करण, जो 4GB डेटाबेस आकार सीमा होती है उपयोग कर रहा है। MSSQL मानक संस्करण पर स्विच करना बहुत महंगा होगा यदि कई डेटाबेस तैनाती हैं, एकल-किरायेदार वेबपैप्स या एम्बेडेड डीबीएमएस वाले अनुप्रयोगों में होंगे। सस्ता SQL2008 वेब संस्करण यहां सहायता कर सकता है।

  2. nvarchar (4000) काफी नहीं है, लेकिन आप एक ntext स्तंभ नहीं चाहते। तो आप वर्चर (8000) में कनवर्ट करें। हालांकि, अधिकांश मामलों में आपको शायद nvarchar (अधिकतम) में परिवर्तित करना चाहिए।

स्रोत

2008-11-23 10:15:26 mika

18

आप स्तंभ के विभिन्न प्रकार के लिए NVARCHAR से अधिक VARCHAR का चयन करना चाहिए, और विकल्प एक प्रति स्तंभ के आधार पर किया जाएगा।

विशिष्ट स्तंभों जो अतिरिक्त भूमि के ऊपर NVARCHAR incurs की आवश्यकता नहीं होगी होगा:

आईडी प्रकार कॉलम: लाइसेंस प्लेट, SSNs, रोगी चार्ट पहचानकर्ता आदि

कोड कॉलम: अंतर्राष्ट्रीय मुद्रा कोड (USD, यूकेपी, आदि), आईएसओ देश कोड (यूएस, यूके, आदि), भाषा कोड (एन-यूएस, आदि), लेखांकन सेगमेंट कोड, आदि

डाक कोड और ज़िप कोड कॉलम।

स्रोत

2008-11-24 05:22:23

1

मैंने कुछ डेटाबेस देखा है जहां सूचकांक (इंडेक्स? ... विभिन्न बहस) डेटा से बड़े हैं। यदि कोई इंडेक्स के भीतर स्टोरेज मांगों (वर्कर) के साथ आधे से दूर हो सकता है तो कोई मानता है कि किसी दिए गए पृष्ठ की हिट घनत्व से दोगुनी होती है और अधिक कुशल भरने-फैक्टरिंग की वजह से तेजी से डेटा पुनर्प्राप्ति/लेखन/लॉकिंग & कम संग्रहण आवश्यकताओं (पहले ही उल्लेख किया)।

स्रोत

2011-03-08 15:09:36

1

मेरा झुकाव डिफ़ॉल्ट रूप से "NVARCHAR का उपयोग करें" है ... लेकिन @CadeRoux का एक अच्छा बिंदु है: यदि आप सुनिश्चित हैं कि डेटा कभी भी कुछ भी नहीं रखेगा लेकिन ASCII - यूएस लाइसेंस प्लेट की तरह - VARCHAR आपको बचा सकता है लागत का एक छोटा सा हिस्सा।

मैं कहूंगा कि उनके अच्छी तरह से दिए गए बयान का फ्लिप पक्ष "किसी भी चीज़ के लिए एनवीएआरएआरएआर का उपयोग करें" नाम (लोगों, सड़कों, स्थानों) या प्राकृतिक भाषा पाठ (ईमेल, चैट, लेख, ब्लॉग पोस्टिंग, फोटो कैप्शन)। अन्यथा, आपका "पहला नाम" कॉलम "फ़्रैंकोइस" या "जोसे" को सही ढंग से एन्कोड करने में सक्षम नहीं होगा, और आपके टेक्स्ट कॉलम टेक्स्ट को "विदेशी" डायक्रिटिकल अंक के साथ अनुमति नहीं देंगे, या - उस मामले के लिए - बहुत आम अमेरिकी अक्षर जैसे सेंट-मार्क "¢", अनुच्छेद चिह्न "¶", एक बुलेट "•"।(। क्योंकि उन में से कोई भी ASCII वर्ण कर रहे हैं, और वहाँ कोई अच्छा, मानक उन्हें एक VARCHAR क्षेत्र के लिए में डालने के लिए रास्ता नहीं है मुझ पर विश्वास करो: तुम अपने आप को चोट लगी होगी।)

किसी भी परियोजना मैं पर काम किया है पर , मुझे कभी भी NVARCHAR का उपयोग करने के लिए डांटा नहीं गया है क्योंकि मैं "डिस्क स्पेस पर बहुत अधिक कंपनी धन गंवा रहा था"। और अगर मुझे कोड या डीबी स्कीमा (विशेष रूप से लाइव, प्रोडक्शन सिस्टम पर) को फिर से काम करना पड़ा, तो फिर से फिट में खर्च की गई लागत आसानी से "बचत" से 50% छोटी डिस्क खरीदने से अधिक होगी।

वास्तव में इस प्रश्न को समझने के लिए आपको वास्तव में एएससीआईआई, यूनिकोड, और यूनिकोड के विशिष्ट एन्कोडिंग (जैसे यूसीएस -2 और यूटीएफ -8) को समझना होगा।

स्रोत

2012-08-29 03:29:38

+0

एक NVARCHAR (12) 24-बाइट लेगा, और बीएमपी में किसी भी 12 अक्षर, या इसके बाहर के 6 वर्ण रख सकते हैं। एक 8-बिट-पारदर्शी वर्चर (24), उपयुक्त पहुंच विधियों के साथ उपयोग किया जाता है, इसमें 24 ASCII वर्ण हो सकते हैं, बीएमपी के निम्नतम भाग में कोई भी 12 वर्ण, बीएमपी में कोई भी 8, या बीएमपी के बाहर कोई भी 6; वैकल्पिक रूप से, इसका उपयोग एन्कोडिंग का उपयोग करके 8 वर्णों के किसी भी संयोजन को पकड़ने के लिए किया जा सकता है जो प्रति चरित्र 3 बाइट्स स्टोर करता है, उदा। प्रत्येक तीन तिहाई सेट के पहले बाइट पर एमएसबी सेट के साथ और दूसरे दो पर मंजूरी दे दी। – supercat

संबंधित मुद्दे

 संबंधित मुद्दे