हर बार जब मैं एक टेबल बनाता हूं तो मुझे आश्चर्य होता है कि क्या कोई प्रदर्शन अंतर है यदि मैं nvarchar (100) या nvarchar (1000) कहता हूं कि वास्तविक स्ट्रिंग आकार 100 से कम होगा। तो क्या वहाँ है?क्या आकार NVARCHAR के साथ प्रयोग किया जाता है?
the documentation के अनुसार:
nvarchar [(एन | अधिकतम)]
चर लंबाई यूनिकोड स्ट्रिंग डेटा। n स्ट्रिंग लंबाई को परिभाषित करता है और 1 से 4,000 का मान हो सकता है। अधिकतम इंगित करता है कि अधिकतम संग्रहण आकार 2^31-1 बाइट्स (2 जीबी) है। बाइट्स में भंडारण आकार, 2 बाइट्स दर्ज किए गए डेटा की वास्तविक लंबाई दो गुना है।
तो, स्टोरेज आकार की गणना करते समय डेटा की वास्तविक लंबाई केवल मामलों में दर्ज की गई।
प्रलेखन यह नहीं कहता कि यह क्यों है, लेकिन लंबाई पैरामीटर उपयोगी है क्योंकि यह सरल सीमा बाधाओं को लागू करता है (उदाहरण के लिए, इसलिए कोई व्यक्ति अपने "नाम" के रूप में 2 जीबी टेक्स्ट दर्ज नहीं कर सकता)।
दरअसल, अगर कोई अलग कारण है तो कुछ बाधा क्यों डाली जानी चाहिए तो यह बाधा जोड़ने का एक अच्छा कारण है। शायद एक व्यापार नियम है जो कहता है "डेटा तत्व एक्स कभी वाई वर्णों से अधिक नहीं हो सकता है।" या शायद सिस्टम के किसी अन्य हिस्से पर एक बाधा है और पूरे सिस्टम में डेटा अखंडता को बनाए रखने के लिए, पूरे सिस्टम में बाधा को बनाए रखा जाना चाहिए। – David
सही। ध्यान दें कि nvarchar (अधिकतम) अलग-अलग संग्रहीत किया जाता है और इसे केवल nvarchar (x) के प्रतिस्थापन के रूप में उपयोग नहीं किया जाना चाहिए। स्टोरेज स्पेस एक जैसा है, लेकिन यह एक इनलाइन फ़ील्ड की तुलना में बीएलओबी की तरह अधिक संग्रहीत है। –
मैंने वॉरचर के बजाय nvarchar का उपयोग करने के लिए http://rusanu.com/2010/03/22/performance-comparison-of-varcharmax-vs-varcharn/ पर परीक्षणों को ट्वीव करके एंड्रयूबार्बर की टिप्पणी को अभी सत्यापित किया है। – StriplingWarrior
चूंकि nvarchar एक परिवर्तनीय लंबाई डेटा प्रकार है, यह केवल उस डेटा को संग्रहीत करेगा जो आप इसे आवंटित करते हैं (2 बाइट प्रति चार) प्लस 2 बाइट्स लंबाई की जानकारी के लिए और मुख्य रूप से चीनी जैसे डबल बाइट भाषाओं के लिए उपयोग किया जाता है।
व्यक्तिगत रूप से, जब मैं एक निश्चित सीमा (यानी यूआरएल क्वेरी स्ट्रिंग सीमा, फ़ाइल पथ एसजीई सीमा, या अपनी सीमा) के बारे में जानता हूं तो मैं वर्कर (एन) का उपयोग करता हूं। मैं वर्चर (अधिकतम) का उपयोग करता हूं जब अधिकतम लंबाई अपरिभाषित होती है और यह 8000 वर्णों से आगे जा सकती है। और मैं मुख्य रूप से कभी भी nvarchar का उपयोग नहीं करता क्योंकि हमारा आवेदन कभी अंतरराष्ट्रीय नहीं होगा।
जब आपको nvarchar (1000) की आवश्यकता होती है तो आपको nvarchar (1000) का उपयोग क्यों नहीं करना चाहिए, खराब डेटा को आपके डेटाबेस में प्रवेश करने से रोकने में मदद करना है। जब तक आप इसे पसंद नहीं करते हैं, जब फोन नंबरों का कहना है कि 'वसा सचिव को बुलाएं, अगर आप एक वास्तविक जवाब चाहते हैं तो प्यारा नहीं है। "(इतना यादृच्छिक उदाहरण नहीं है कि मुझे एक बार हमें भेजा गया वास्तविक ग्राहक फ़ाइल में मिला) उपयोगकर्ता बहुत तेज़ी से पता लगाएंगे कौन से फ़ील्ड इतने बड़े हैं कि वे नोट्स स्टोर करने के लिए उनका उपयोग कर सकते हैं जिसमें समय के साथ बेकार क्षेत्र में डेटा बनाना पड़ता है।
और nvarchar (अधिकतम) के लिए, यह तब तक उपयोग करना एक बुरा विचार है आप 4000 से अधिक वर्ण होने की उम्मीद करते हैं। क्यों देखें
दूसरी तरफ, मैं इसे ज्यादातर मामलों में केवल "अंतिम सैनिटी चेक" मानता हूं। यही है, एक टेलीफोन नंबर के लिए मैं शायद अलग-अलग क्षेत्र/देश कोड, एक्सटेंशन और ऐसे खातों के लिए 'वर्चार (20) '(मुझे 10, 20, 100, 200 तक जाना पसंद है) का उपयोग करना होगा। यह सुनिश्चित करने के लिए कि डेटा जो भी व्यवसाय नियमों के अनुरूप है, आमतौर पर * अतिरिक्त * डेटा सत्यापन बाधाओं (डीबी, डीएएल, या अन्यथा का हिस्सा) होना चाहिए। –
सवाल "प्रदर्शन अंतर" के बारे में पूछ रहा है। –
आकार बनाम प्रदर्शन के लिए, याद रखें कि SQL सर्वर nvarchar/varchar और पूरे मान के लिए डेटा के प्रारंभिक मान को संग्रहीत करेगा nchar/के लिए अंतरिक्ष के मामले में। उदाहरण के लिए: nvarchar(1000) संग्रहीत डेटा के साथ test data प्रारंभ में 9 * 2 बाइट स्पेस या 18-बाइट्स लेगा। जबकि nchar(1000) 1000 * 2 बाइट्स (2000-बाइट्स) लेगा, इससे कोई फर्क नहीं पड़ता।
फिर पृष्ठ पर डेटा के अगले सेट को जोड़ने के अपने मजेदार तरीके से यह बढ़ता है (जो 8k है) जब तक कि तालिका तालिका के भरने के लिए भरने वाले कारक (या उसके करीब) न हो। फिर एक नया पेज शुरू होता है। अब मान लें कि किसी उपयोगकर्ता को उस डेटा को अपडेट करने और पिछले फ़ील्ड में कुछ पदार्थों के साथ कुछ प्रविष्ट करने की आवश्यकता है, मान लें कि कुछ 800 अक्षर लंबे हैं। अब उस मान को अद्यतन करने और महत्वपूर्ण रूप से बढ़ने की जरूरत है, लेकिन अब पृष्ठ भर गया है और जब उस क्षेत्र के डेटा को बढ़ाना है, तो पृष्ठ को विभाजित करने और डेटा के लिए रास्ता बनाने की आवश्यकता है (जब तक कि भरने वाला कारक पर्याप्त नहीं है विकास)।
वह पृष्ठ विभाजित इंडेक्स विखंडन के रूप में समेकित होगा और नतीजे धीमी खोज/तलाश के समय और अधिक अपडेट समय में होगा। इसलिए डेटा में महत्वपूर्ण परिवर्तन होने पर प्रदर्शन के प्रभाव के संदर्भ में अंतर हो सकता है।
जैसा अक्सर होता है, जवाब है: "निर्भर करता है"।
तो आप कह रहे हैं कि nvarchar (1000) अंतरिक्ष के 1000 * 2 बाइट आरक्षित करेगा, भले ही सामग्री केवल 40 बाइट्स लेती है? क्योंकि मैंने सोचा था कि यह नहीं होगा। –
कम से कम SQL सर्वर डेटाबेस में इसे कॉलम के खिलाफ अनन्य बाधा बनाने की अनुमति नहीं है क्योंकि इसके प्रकार nvarchar (max) के रूप में है। इस बाधा को सफलतापूर्वक जोड़ने के लिए इसे nvarchar (450) तक सीमित होना चाहिए।
और कॉलम का कुल आकार 900 बाइट्स से अधिक होने पर प्राथमिक कुंजी बनाने की अनुमति नहीं है, जो आसानी से मामला हो सकता है यदि आप अधिकतम आकार वाले दो nvarchar कॉलम का उपयोग करते हैं, 450 को समग्र प्राथमिक कुंजी के रूप में कहते हैं। –
हां, यह प्रदर्शन बिंदु-दृश्य से महत्वपूर्ण है।
क्वेरी ऑप्टिमाइज़र क्वेरी की योजना बनाने के लिए इस मेटा डेटा को देखता है। यह प्रदान की गई लंबाई के आधार पर पंक्ति आकार का अनुमान लगाता है और इससे प्रदर्शन समस्या हो सकती है। उदाहरण के लिए, जब आपको वर्चर (10) वाले कॉलम को सॉर्ट करने की आवश्यकता होती है, तो यह रैम पर सॉर्ट ऑपरेशन चलाने की योजना बना सकता है, लेकिन वर्चर (1000) के लिए एक ही क्वेरी को माध्यमिक स्टोरेज पर चलाने की योजना बनाई जा सकती है।
मैं डोमेन ज्ञान का उपयोग करने और आवश्यक आकार का अनुमान लगाने का प्रयास करता हूं। इसके अतिरिक्त, आपको भावी रखरखाव के लिए कुछ जगह लगाने की आवश्यकता हो सकती है। उदाहरण के लिए, यदि आपको लगता है कि आपके डेटा में अधिकतम 50 वर्ण हो सकते हैं, तो 50 के बजाय वर्चर (70) का उपयोग करें ताकि यह एप्लिकेशन उपयोग में अप्रत्याशित भविष्य में परिवर्तनों को संभाल सके। आँख बंद करके छोटे लंबाई चयन ना करें:
मैं इस ब्लॉग पोस्ट (मैं लेखक नहीं हूँ) से इसके बारे में पता चल गया: http://aboutsqlserver.com/2010/08/18/what-is-the-optimal-size-for-variable-width-columns/
नोट। क्षेत्र का आकार बदलना एक बड़ा रखरखाव सिरदर्द बन सकता है। मुझे याद है जब मैं LastName फ़ील्ड के लिए एक छोटी सी लंबाई चुनता हूं, और कुछ उपयोगकर्ता इस वजह से सिस्टम में साइन अप नहीं कर सके। हमें उपयोग में एक महत्वपूर्ण डेटाबेस अपडेट करना था (इसमें फील्ड लम्बाई बढ़ाने में समय लगता है), और प्रोग्राम संकलित करें और पुन: नियोजित करें। अगर मैंने उचित क्षेत्र का आकार चुना है, तो मैं इन सभी सिरदर्दों से बच सकता हूं।
आप nvarchar (अधिकतम) और nvarchar (n) के बीच अंतर के बारे में भी पढ़ सकते हैं क्योंकि 4000 के लिए n> 4000 फ़ील्ड मूल रूप से nvarchar (अधिकतम) के समान होता है। (Are there any disadvantages to always using nvarchar(MAX)?)
http://dba.stackexchange.com/q/1767 –