केस असंवेदनशील तार के खिलाफ अनुक्रमण अभी तक डेटा का मामला कायम है। यह वास्तव में कैसे काम करता है?
यह वास्तव में एक SQL सर्वर विशिष्ट व्यवहार नहीं है, यह सिर्फ यह है कि ये चीजें सामान्य रूप से कैसे काम करती हैं।
तो, डेटा डेटा है। यदि आप विशेष रूप से एक इंडेक्स के बारे में बोल रहे हैं, तो डेटा को संग्रहीत करने की आवश्यकता है क्योंकि यह वास्तविक मूल्य प्राप्त करने के लिए हर बार मुख्य तालिका में एक लुक-अप की आवश्यकता होती है, और एक कवर इंडेक्स की संभावना नहीं होगी (पर) कम से कम स्ट्रिंग प्रकार के लिए नहीं)।
डेटा, या तो टेबल / क्लस्टर इंडेक्स या गैर-क्लस्टर इंडेक्स में, कोई कोलाज / सॉर्टिंग जानकारी नहीं होती है। यह केवल डेटा है। टकराना (लोकेल / कल्चर रूल्स एंड सेंसिटिविटीज़) कॉलम से जुड़ा हुआ मेटा डेटा है और इसका उपयोग तब किया जाता है जब एक प्रकार का ऑपरेशन कहा जाता है (जब तक कि एक द्वारा ओवरराइड नहीं किया जाता हैCOLLATEखंड), जिसमें एक सूचकांक का निर्माण / पुनर्निर्माण शामिल होगा। एक गैर-बाइनरी कॉलेशन द्वारा परिभाषित नियमों का उपयोग सॉर्ट-कीज़ को उत्पन्न करने के लिए किया जाता है, जो कि स्ट्रिंग के द्विआधारी निरूपण हैं (सॉर्ट कीज़ बाइनरी कॉल्स में अनावश्यक हैं)। ये बाइनरी अभ्यावेदन सभी स्थानीय / संस्कृति नियमों और चयनित संवेदनशीलता को शामिल करते हैं। सॉर्ट-कीज़ का उपयोग रिकॉर्ड्स को उनके उचित क्रम में रखने के लिए किया जाता है, लेकिन खुद को इंडेक्स या टेबल में संग्रहीत नहीं किया जाता है। वे संग्रहीत नहीं हैं (कम से कम मैंने इन मूल्यों को सूचकांक में नहीं देखा है और कहा गया था कि वे संग्रहीत नहीं हैं) क्योंकि:
- उन्हें वास्तव में छंटाई की आवश्यकता नहीं है क्योंकि वे केवल उसी क्रम में तालिका या अनुक्रमणिका में पंक्तियों के समान होंगे। लेकिन, सूचकांक का भौतिक क्रम केवल क्रमबद्ध है, तुलना नहीं।
- भंडारण करते समय वे तुलनात्मक रूप से तेज कर सकते हैं , यह सूचकांक को भी बड़ा बना देगा क्योंकि किसी एकल वर्ण के लिए न्यूनतम आकार 5 बाइट्स होता है, और यह सिर्फ "ओवरहेड" (सॉर्ट कुंजी संरचना का) है। अधिकांश अक्षर 2 बाइट्स प्रत्येक, प्लस 1 बाइट अगर कोई उच्चारण है, तो प्लस 1 बाइट यदि यह ऊपरी मामला है। उदाहरण के लिए, "ई" एक 7-बाइट कुंजी है, "ई" और "ई" दोनों 8 बाइट्स हैं, और "9" 9-बाइट कुंजी है। इसलिए, अंत में इन भंडारण के लायक नहीं है।
Collations दो प्रकार के होते हैं: SQL Server और Windows।
एस क्यू एल सर्वर
एसक्यूएल सर्वर collations (के साथ शुरू नाम के साथ उन SQL_) पुराने, पूर्व SQL Server 2000 छँटाई / की तुलना में जिस तरह से कर रहे हैं (भले ही SQL_Latin1_General_CP1_CI_ASहै अभी भी , अमेरिका अंग्रेजी OSes पर डिफ़ॉल्ट स्थापना की काफी उदासी)। इस पुराने, सरल, गैर-यूनिकोड मॉडल में, लोकेल, कोड पेज और विभिन्न संवेदनशीलता के प्रत्येक संयोजन को उस कोड पृष्ठ के प्रत्येक अक्षर का एक स्थिर मानचित्रण दिया जाता है। प्रत्येक वर्ण को यह मानने के लिए एक मान (कि तरह वजन) सौंपा गया है कि वह दूसरों के साथ कैसे बराबरी करता है। इस मॉडल में तुलना दो-पास ऑपरेशन करने के लिए दिखाई देती है:
- सबसे पहले, यह सब लहजे को हटा (जैसे कि " ü " हो जाता है " यू "), "जैसे पात्रों का विस्तार Æ " में " एक " और " ई ", ताकि शब्द (एक प्राकृतिक क्रम में हैं आप कैसे होगा एक प्रारम्भिक तरह करता है एक शब्दकोश में उन्हें खोजने की उम्मीद)।
- फिर, यह चरित्र द्वारा इन अंतर्निहित मूल्यों के आधार पर प्रत्येक चरित्र के आधार पर समानता का निर्धारण करता है। यह दूसरा भाग है जिसे मस्टेको अपने उत्तर में वर्णित कर रहा है ।
इन समतुल्यों में समायोजित की जाने वाली एकमात्र संवेदनाएं हैं: "केस" और "एक्सेंट" ("चौड़ाई", "काना टाइप" और "वेरिएशन सिलेक्टर" उपलब्ध नहीं हैं)। इसके अलावा, इन संघों में से कोई भी सप्लीमेंट्री कैरेक्टर का समर्थन नहीं करता है (जो समझ में आता है कि वे यूनिकोड-विशिष्ट हैं और ये कॉलेशन केवल गैर-यूनिकोड डेटा पर लागू होते हैं)।
यह दृष्टिकोण केवल गैर-यूनिकोड VARCHARडेटा पर लागू होता है । लोकेल, कोड पेज, केस-सेंसिटिविटी और एक्सेंट-सेंसिटिविटी के प्रत्येक विशिष्ट संयोजन में एक विशिष्ट "सॉर्ट आईडी" है, जिसे आप निम्नलिखित उदाहरण में देख सकते हैं:
SELECT COLLATIONPROPERTY(N'SQL_Latin1_General_CP1_CI_AS', 'SortID'), -- 52
COLLATIONPROPERTY(N'SQL_Latin1_General_CP1_CS_AS', 'SortID'), -- 51
COLLATIONPROPERTY(N'Latin1_General_100_CI_AS', 'SortID'); -- 0
पहले दो कोलाज के बीच एकमात्र अंतर केस-सेंसिटिविटी है। तीसरा टकराव एक विंडोज कोलाजेशन है और इसलिए इसमें स्टैटिक मैपिंग टेबल नहीं है।
इसके अलावा, इन collations को सॉर्ट करना चाहिए और वज़न को सॉर्ट करने के लिए साधारण लुकअप होने के कारण विंडोज कॉलेशन की तुलना में तेज़ी से तुलना करनी चाहिए। हालांकि, ये टकराव बहुत कम कार्यात्मक हैं और यदि संभव हो तो आमतौर पर इसे टाला जाना चाहिए।
खिड़कियाँ
विंडोज कोलाजेशन (जिनके नाम शुरू नहींSQL_ हैं) सॉर्टिंग / तुलना करने का नया (एसक्यूएल सर्वर 2000 में शुरू) तरीका है। इस नए, जटिल, यूनिकोड मॉडल में, लोकेल के प्रत्येक संयोजन, कोड पेज, और विभिन्न संवेदनाओं को स्थैतिक मानचित्रण नहीं दिया गया है। एक बात के लिए, इस मॉडल में कोई कोड पृष्ठ नहीं हैं। यह मॉडल प्रत्येक वर्ण के लिए एक डिफ़ॉल्ट सॉर्ट मान प्रदान करता है, और फिर प्रत्येक स्थान / संस्कृति किसी भी वर्ण के लिए सॉर्ट मान पुन: असाइन कर सकता है। यह कई संस्कृतियों को अलग-अलग तरीकों से एक ही वर्ण का उपयोग करने की अनुमति देता है। यह कई भाषाओं के लिए समान कोलाज का उपयोग करके स्वाभाविक रूप से सॉर्ट किए जाने की अनुमति देने का प्रभाव रखता है यदि वे समान वर्णों का उपयोग नहीं करते हैं (और यदि उनमें से किसी को किसी भी मान को फिर से असाइन करने की आवश्यकता नहीं है और बस चूक का उपयोग कर सकते हैं)।
इस मॉडल में सॉर्ट मान एकल मान नहीं हैं। वे मानों की एक सरणी है जो आधार पत्र के सापेक्ष भार को असाइन करते हैं, किसी भी डायक्ट्रीकिक्स (अर्थात उच्चारण), आवरण, आदि। यदि टकराव केस-संवेदी है, तो उस सरणी के "केस" भाग का उपयोग किया जाता है, अन्यथा इसे अनदेखा किया जाता है ( इसलिए, असंवेदनशील)। यदि टकराव उच्चारण-संवेदी है, तो "सरणी" भाग का उपयोग किया जाता है, अन्यथा इसे अनदेखा किया जाता है (इसलिए, असंवेदनशील)।
इस मॉडल में तुलना एक बहु-पास ऑपरेशन है:
- सबसे पहले, स्ट्रिंग को सामान्य किया जाता है ताकि एक ही चरित्र का प्रतिनिधित्व करने के विभिन्न तरीके समान होंगे। उदाहरण के लिए, " ü " एकल वर्ण / कोड बिंदु (U + 00FC) हो सकता है। आप एक गैर-उच्चारण " u " (U + 0075) को एक संयोजन Diaeresis "+" (U + 0308) के साथ भी प्राप्त कर सकते हैं: " ü ", जो न केवल तब ही दिखता है जब तक कि इसका प्रतिपादन नहीं किया जाता (जब तक कि इसमें कोई समस्या न हो) आपका फ़ॉन्ट), लेकिन एकल वर्ण संस्करण (U + 00FC) के समान भी माना जाता है, जब तक कि बाइनरी कॉलेशन (जो वर्णों के बजाय बाइट्स की तुलना करता है) का उपयोग नहीं करता है। सामान्यकरण एकल वर्ण को विभिन्न टुकड़ों में तोड़ता है, जिसमें " the " (SQL सर्वर कोलाज़ के लिए ऊपर उल्लिखित) जैसे वर्णों के विस्तार शामिल हैं ।
- इस मॉडल में तुलना ऑपरेशन प्रत्येक संवेदनशीलता के अनुसार चरित्र द्वारा चरित्र में जाता है । स्ट्रिंग्स के लिए सॉर्ट कीज़ प्रत्येक मूल्यों के उचित तत्वों को लागू करने के द्वारा निर्धारित की जाती हैं, जो मूल्यों की सरणी सरणी पर आधारित होती हैं, जिस पर संवेदनशीलता "संवेदनशील" होती है। सॉर्ट कुंजी मानों को प्रत्येक वर्ण (आधार वर्ण) की प्राथमिक संवेदनाओं के द्वारा व्यवस्थित किया जाता है, इसके बाद सभी माध्यमिक संवेदनशीलता (डायक्रिटिक वजन), प्रत्येक वर्ण के केस वेट और उसके बाद।
- सॉर्ट की गई गणना सॉर्ट कुंजियों के आधार पर की जाती है। एक साथ समूहीकृत संवेदनशीलता के साथ, आप एक भिन्न SQL सर्वर कोलाज़ के साथ एक अलग प्रकार का क्रम प्राप्त कर सकते हैं जब कई वर्णों के तार की तुलना की जाती है, और लहजे शामिल होते हैं, और टकराव उच्चारण-संवेदी होता है (और इससे भी अधिक यदि टकराव होता है केस-संवेदी भी)।
इस छँटाई के बारे में अधिक जानकारी के लिए, मैं अंततः एक पोस्ट प्रकाशित करूँगा, जो क्रमबद्ध प्रमुख मानों को दिखाता है, उनकी गणना कैसे की जाती है, SQL सर्वर और Windows collations के बीच अंतर, आदि। लेकिन अभी के लिए, कृपया मेरा उत्तर देखें: Accent Sensitive Sort ( कृपया ध्यान दें कि उस प्रश्न का अन्य उत्तर आधिकारिक यूनिकोड एल्गोरिथ्म की एक अच्छी व्याख्या है, लेकिन एसक्यूएल सर्वर इसके बजाय एक कस्टम का उपयोग करता है, हालांकि समान एल्गोरिथ्म, और यहां तक कि एक कस्टम वजन तालिका)।
सभी संवेदनाओं को इन संघों में समायोजित किया जा सकता है: "केस", "उच्चारण", "चौड़ाई", "काना प्रकार", और "भिन्नता चयनकर्ता" (SQL सर्वर 2017 में शुरू, और केवल जापानी कोलाज के लिए)। इसके अलावा, इनमें से कुछ टकराव (जब यूनिकोड डेटा के साथ उपयोग किया जाता है) सप्लीमेंट्री कैरेक्टर (SQL सर्वर 2012 में शुरू) का समर्थन करते हैं। यह दृष्टिकोण NVARCHAR और VARCHAR डेटा (यहां तक कि गैर-यूनिकोड डेटा) दोनों पर लागू होता है । यह VARCHARपहले यूनिकोड के मूल्य को आंतरिक रूप से परिवर्तित करके और फिर सॉर्ट / तुलना नियमों को लागू करके गैर-यूनिकोड डेटा पर लागू होता है।
कृपया ध्यान दें:
- SQL सर्वर के लिए कोई सार्वभौमिक डिफ़ॉल्ट कॉलेशन नहीं है। एक इंस्टॉलेशन डिफ़ॉल्ट है जो इंस्टॉलेशन के समय ओएस की वर्तमान लोकेल / भाषा सेटिंग के आधार पर भिन्न होता है (जो दुर्भाग्य
SQL_Latin1_General_CP1_CI_ASसे अमेरिकी अंग्रेजी प्रणालियों के लिए है, इसलिए कृपया इस सुझाव के लिए वोट करें )। इसे स्थापना के दौरान बदला जा सकता है। यह उदाहरण-स्तरीय कोलाज तब [model]DB के लिए कोलाजेशन सेट करता है जो नए DBs बनाते समय उपयोग किया जाने वाला टेम्पलेट है, लेकिन क्लॉज CREATE DATABASEको निर्दिष्ट करके निष्पादित करते समय कोलाज को बदला जा सकता है COLLATE। इस डेटाबेस-स्तर के टकराव का उपयोग चर और स्ट्रिंग शाब्दिक, साथ ही नए (और परिवर्तित!) कॉलम के लिए किया जाता है जब COLLATEक्लॉज निर्दिष्ट नहीं किया जाता है (जो प्रश्न में उदाहरण कोड के लिए मामला है)।
- Collations / encodings / यूनिकोड के बारे में अधिक जानकारी के लिए, कृपया देखें: Collations Info