कुछ अन्य RDBMS के विपरीत, जो एक एन्कोडिंग चुनने की अनुमति देते हैं, SQL सर्वर यूनिकोड डेटा को केवल संग्रहीत करता है UTF-16 (लिटिल एंडियन) में, और गैर-यूनिकोड डेटा 8-बिट एन्कोडिंग (विस्तारित ASCII, DBCS, या EBCDIC) में जो भी कोड पेज फ़ील्ड के संयोजन द्वारा निहित है।
चुनने . का उनका निर्णय UCS-2 पर्याप्त समझ में आता है क्योंकि UTF-16 को 1996 के मध्य में पेश किया गया था और 2000 में पूरी तरह से निर्दिष्ट किया गया था। बहुत से अन्य सिस्टम इसका उपयोग (या उपयोग) भी करते हैं (कृपया देखें:https://en.wikipedia.org/wiki/UTF-16#Usage ) जारी रखने . का उनका निर्णय इसके साथ यह अधिक संदिग्ध हो सकता है, हालांकि यह संभवतः विंडोज़ और .NET के यूटीएफ -16 होने के कारण है। बाइट्स का भौतिक लेआउट UCS-2 और UTF-16 के बीच समान है, इसलिए UCS-2 से UTF-16 का समर्थन करने के लिए सिस्टम को अपग्रेड करना किसी भी मौजूदा डेटा को बदलने की आवश्यकता के बिना विशुद्ध रूप से कार्यात्मक होना चाहिए।
उम नहीं। SQLCLR के माध्यम से एक कस्टम उपयोगकर्ता-परिभाषित प्रकार बनाना नहीं है , किसी भी तरह से, आपको किसी भी देशी प्रकार का प्रतिस्थापन दिलाने जा रहा है। विशेष डेटा को संभालने के लिए कुछ बनाने के लिए यह बहुत आसान है। लेकिन स्ट्रिंग्स, यहां तक कि एक अलग एन्कोडिंग के भी, विशेष से बहुत दूर हैं। अपने स्ट्रिंग डेटा के लिए इस मार्ग पर जाने से आपके सिस्टम की उपयोगिता की कोई भी मात्रा नष्ट हो जाएगी, प्रदर्शन का उल्लेख नहीं करने के लिए क्योंकि आप किसी भी का उपयोग करने में सक्षम नहीं होंगे। अंतर्निहित स्ट्रिंग फ़ंक्शन। यदि आप डिस्क स्थान पर कुछ भी बचाने में सक्षम थे, तो उन लाभों को मिटा दिया जाएगा जो आप समग्र प्रदर्शन में खो देंगे। UDT को एक VARBINARY . पर क्रमांकित करके संग्रहीत किया जाता है . तो कोई भी करने के लिए स्ट्रिंग तुलना या छँटाई, एक "बाइनरी" / "ऑर्डिनल" तुलना के बाहर, आपको अन्य सभी मानों को एक-एक करके वापस UTF-8 में बदलना होगा, फिर स्ट्रिंग तुलना करें जो भाषाई अंतरों को ध्यान में रख सके।
साथ ही, वह "दस्तावेज़ीकरण" वास्तव में केवल नमूना कोड/अवधारणा सामग्री का प्रमाण है। कोड 2003 में लिखा गया था ( http://msftengprodsamples.codeplex.com/SourceControl/latest#Kilimanjaro_Trunk/Programmability/CLR/UTF8String/CS/UTF8String/Utf8String.cs ) SQL सर्वर 2005 के लिए। मैंने कार्यक्षमता का परीक्षण करने के लिए एक स्क्रिप्ट देखी, लेकिन प्रदर्शन से संबंधित कुछ भी नहीं।
हां बिलकुल वही। डिफ़ॉल्ट रूप से, अंतर्निहित कार्यों की हैंडलिंग केवल UCS-2 के लिए है। लेकिन SQL सर्वर 2012 में शुरू करके, आप उन्हें पूर्ण UTF-16 वर्ण सेट (ठीक है, यूनिकोड संस्करण 5 या 6 के रूप में, आपके OS और .NET फ्रेमवर्क के संस्करण के आधार पर) को संभालने के लिए प्राप्त कर सकते हैं। जिसका नाम _SC . से समाप्त होता है (अर्थात पूरक वर्ण)।
सही। UTF-16 और UCS-2 दोनों ही 2-बाइट कोड पॉइंट का उपयोग करते हैं। लेकिन UTF-16 उनमें से कुछ का उपयोग जोड़े (यानी सरोगेट जोड़े) में अतिरिक्त वर्णों को मैप करने के लिए करता है। इन जोड़ियों के लिए उपयोग किए गए कोड बिंदु UCS-2 में इस उद्देश्य के लिए आरक्षित हैं और इसलिए किसी भी प्रयोग करने योग्य प्रतीकों को मैप करने के लिए उपयोग नहीं किए जाते हैं। यही कारण है कि आप किसी भी यूनिकोड वर्ण को SQL सर्वर में संग्रहीत कर सकते हैं और इसे सही ढंग से संग्रहीत और पुनर्प्राप्त किया जाएगा।
सही, हालांकि भ्रामक। हां, UTF-8 चर-चौड़ाई है, लेकिन UTF-16 भी मामूली रूप से परिवर्तनशील है क्योंकि सभी पूरक वर्ण दो डबल-बाइट कोड बिंदुओं से बने होते हैं। इसलिए UTF-16 प्रति प्रतीक 2 या 4 बाइट्स का उपयोग करता है, हालांकि UCS-2 हमेशा 2 बाइट्स होता है। लेकिन यह भ्रामक हिस्सा नहीं है। भ्रामक बात यह है कि कोई अन्य यूनिकोड एन्कोडिंग अन्य सभी कोड बिंदुओं को एन्कोड करने में सक्षम नहीं है। जबकि UCS-2 उन्हें पकड़ सकता है लेकिन उनकी व्याख्या नहीं कर सकता, UTF-16 और UTF-32 दोनों ही UTF-8 की तरह सभी यूनिकोड कोड बिंदुओं को मैप कर सकते हैं।
यह सच हो सकता है, लेकिन यह एक परिचालन दृष्टिकोण से पूरी तरह अप्रासंगिक है।
फिर से, सच है, लेकिन पूरी तरह अप्रासंगिक है क्योंकि UTF-16 और UTF-32 भी सभी यूनिकोड कोड बिंदुओं को मैप करते हैं।
परिस्थितियों के आधार पर यह बहुत अच्छी तरह से सच हो सकता है, और आप इस तरह के बेकार उपयोग के बारे में चिंतित होने के लिए सही हैं। हालाँकि, जैसा कि मैंने उस प्रश्न में उल्लेख किया है जो इसे आगे बढ़ाता है ( UTF-8 सपोर्ट, SQL Server 2012 और UTF8String UDT
), यदि अधिकांश पंक्तियाँ VARCHAR में फ़िट हो सकती हैं, तो आपके पास व्यर्थ स्थान की मात्रा को कम करने के लिए कुछ विकल्प हैं फिर भी कुछ को NVARCHAR होना चाहिए . सबसे अच्छा विकल्प ROW COMPRESSION या PAGE COMPRESSION को सक्षम करना है (केवल एंटरप्राइज़ संस्करण!) SQL Server 2008 R2 से शुरू होकर, वे गैर-MAX NVARCHAR . की अनुमति देते हैं "यूनिकोड के लिए मानक संपीड़न योजना" का उपयोग करने के लिए क्षेत्र जो कम से कम यूटीएफ -8 जितना अच्छा है, और कुछ मामलों में यह यूटीएफ -8 से भी बेहतर है। NVARCHAR(MAX) फ़ील्ड इस फैंसी संपीड़न का उपयोग नहीं कर सकते हैं , लेकिन उनके IN ROW डेटा नियमित ROW और/या पेज कंप्रेशन से लाभ उठा सकते हैं। कृपया इस संपीड़न के विवरण के लिए निम्नलिखित देखें और इसके लिए डेटा आकारों की तुलना करने वाला चार्ट:अपरिष्कृत UCS-2 / UTF-16, UTF-8, और UCS-2 / UTF-16 जिसमें डेटा संपीड़न सक्षम है।
SQL Server 2008 R2 - UCS2 संपीड़न यह क्या है - SAP सिस्टम पर प्रभाव
कृपया डेटा संपीड़न के लिए MSDN पृष्ठ भी देखें। अधिक विवरण के लिए क्योंकि कुछ प्रतिबंध हैं (इसके अलावा यह केवल एंटरप्राइज़ संस्करण में उपलब्ध है - लेकिन सभी को उपलब्ध कराया गया है) SQL सर्वर 2016, SP1 !!) से शुरू होने वाले संस्करण और कुछ परिस्थितियाँ जब संपीड़न चीजों को बदतर बना सकता है।
उस कथन की सत्यता इस बात पर निर्भर करती है कि कोई "डिस्क" को कैसे परिभाषित करता है। यदि आप कमोडिटी के पुर्जों की बात कर रहे हैं, तो आप अपने डेस्कटॉप/लैपटॉप में उपयोग के लिए किसी स्टोर पर शेल्फ से खरीद सकते हैं, तो सुनिश्चित करें। लेकिन, अगर उद्यम-स्तर के भंडारण के संदर्भ में बोलते हैं जो आपके उत्पादन प्रणालियों के लिए उपयोग किया जाएगा, तो बजट को नियंत्रित करने वाले को यह समझाने में मज़ा लें कि उन्हें उस मिलियन-प्लस-डॉलर सैन को अस्वीकार नहीं करना चाहिए जो आप चाहते हैं क्योंकि यह "सस्ता" है ";-)।
मैं किसी के बारे में सोच नहीं सकता। ठीक है, जब तक आप उस UDT को लागू करने, या सभी स्ट्रिंग्स को VARBINARY में बदलने जैसे कुछ करने के लिए किसी भयानक सलाह का पालन नहीं करते हैं , या NVARCHAR(MAX) . का उपयोग कर रहे हैं सभी स्ट्रिंग फ़ील्ड के लिए;-)। लेकिन जिन सभी चीजों के बारे में आप चिंता कर सकते हैं, उनमें से SQL सर्वर UCS-2 / UTF-16 का उपयोग कर रहा है, उनमें से एक नहीं होना चाहिए।
लेकिन, अगर किसी कारण से UTF-8 के लिए कोई मूल समर्थन नहीं का यह मुद्दा अति महत्वपूर्ण है, तो आपको उपयोग करने के लिए एक और RDBMS खोजने की आवश्यकता हो सकती है जो UTF-8 के लिए अनुमति देता है।
अद्यतन 2018-10-02
हालांकि यह अभी तक एक व्यवहार्य विकल्प नहीं है, SQL सर्वर 2019 VARCHAR में UTF-8 के लिए मूल समर्थन पेश करता है / CHAR डेटा के प्रकार। वर्तमान में इसके उपयोग के लिए इसके साथ बहुत अधिक बग हैं, लेकिन यदि उन्हें ठीक कर दिया गया है, तो यह कुछ के लिए एक विकल्प है। परिदृश्य कृपया मेरी पोस्ट देखें, "मूल UTF-8 SQL सर्वर 2019 में समर्थन:उद्धारकर्ता या झूठा पैगंबर?
", इस नई सुविधा के विस्तृत विश्लेषण के लिए।
