और Collation क्या अंतर चुनता है?

यह लेख "एमएस SQL ​​सर्वर डेवलपर" पाठ्यक्रम के छात्रों के लिए तैयार किया गया था।
मैं पिछली परियोजनाओं में से एक से एक कहानी साझा करना चाहता हूं, जो बताता है कि Collation को बहुत सावधानी से चुना जाना चाहिए। और क्या होता है अगर इस पैरामीटर को फिर भी गलत तरीके से चुना जाता है, और समस्या को हल करने के लिए क्या विकल्प मौजूद हैं।

सबसे पहले, कोलाज क्या है पर एक छोटा सा परिचय। SQL सर्वर में, Collation पैरामीटर सर्वर को पंक्तियों को क्रमबद्ध और तुलना करने का तरीका बताता है। उदाहरण के लिए, लाइनें "Apple" और "Apple"। वे अलग हैं या नहीं? यह निर्दिष्ट Collation पर निर्भर करता है। यदि रजिस्टर कम या कम स्पष्ट हो रहा है, तो "क्रिसमस ट्री" और "क्रिसमस ट्री" के उदाहरण के साथ क्या करना है? उन्हें समान या भिन्न के रूप में गिनें? यही सब Collation में भी है।

कहानी एक ऐसी परियोजना में हुई जिसकी कार्यक्षमता ड्रॉपबॉक्स या Google ड्राइव के समान है। यह विभिन्न मशीनों पर उनके सिंक्रनाइज़ किए गए फ़ोल्डर और फ़ाइलों को प्रबंधित करने की क्षमता प्रदान करता है, साथ ही अन्य उपयोगकर्ताओं के लिए इस सिंक्रनाइज़ फ़ोल्डर तक पहुंच की क्षमता भी प्रदान करता है।

तो, कहानी इस तथ्य से शुरू हुई कि प्रोडक्ट सर्वर पर लॉग्स में 75-90% त्रुटियां थीं (नीचे स्क्रीनशॉट देखें), और यह स्पष्ट नहीं है कि वे कहां से आए थे, और उनका कारण क्या था। त्रुटि थी: "ReadWrtLst पूरा नहीं हुआ है"। इसके बाद उपयोगकर्ता के विवरण और उनके फ़ोल्डर आए।

कोड को जल्दी से एक जगह मिली जिसने एक त्रुटि उत्पन्न की, लेकिन हम यह नहीं समझ पाए कि यह क्यों हुआ और इसे कैसे पुन: उत्पन्न करना है। यह केवल यह स्पष्ट था कि त्रुटि किसी भी तरह से संबंधित थी कि उपयोगकर्ता किसी तरह कामयाब रहे। अपने ओएस में एक ही नाम के साथ एक और फ़ोल्डर बनाएं।

हमने उन उपयोगकर्ताओं के बारे में जानकारी एकत्र की है जिनके लिए यह त्रुटि जारी की गई है। और यहां हमें पहले आश्चर्य का सामना करना पड़ा: सिस्टम के लाखों उपयोगकर्ताओं में से, उनमें से केवल 50 के पास यह त्रुटि थी। और इन 50 उपयोगकर्ताओं ने 90% त्रुटि लॉग उत्पन्न किए। चूंकि स्थिति को पुन: प्रस्तुत नहीं किया जा सकता था, हमने उपयोगकर्ताओं में से एक से संपर्क करने और यह पता लगाने का निर्णय लिया कि किसी एक फ़ोल्डर को इसके साथ क्यों नहीं सिंक्रनाइज़ किया गया है। फ़ोल्डर ने हमें दूसरों के समान ही देखा, केवल अंतर यह था कि इसे उपयोगकर्ता की भाषा में चित्रलिपि का उपयोग करके बुलाया गया था। और उपयोगकर्ता जापानी था। वैसे, इन 50 उपयोगकर्ताओं में, जापानी बहुसंख्यक थे।

टीम के डेवलपर्स में से एक के लिए धन्यवाद, हम त्रुटि को पुन: उत्पन्न करने में सक्षम थे। त्रुटि यह थी कि ऑपरेटिंग सिस्टम ने फ़ोल्डर नामों को अलग माना, और SQL सर्वर ने उन्हें चयनित Collation के कारण समान माना।

परियोजना में उपयोग किया गया कोलाजेशन:
SQL_Latin1_General_CP1_CI_AS

Collation पढ़ने के तरीके पर एक छोटा सा विषयांतर। (यदि आप इससे परिचित हैं तो बेझिझक इसे छोड़ दें।)

तो, Collation के कई भाग हैं:

• एसक्यूएल - एसक्यूएल सर्वर (कोलाजेशन की शुरुआत में एसक्यूएल) या विंडोज (फिर यह सिर्फ लैटिन 1 होगा ...) द्वारा सॉर्टिंग विकल्प;
• लैटिन 1_ जेनरल - स्थानीय या प्रयुक्त भाषा;
• CP1 - कोड पृष्ठ - कोड पृष्ठ;
• सीआई - केस असंवेदनशील - केस असंवेदनशील;
• एएस - एक्सेंट सेंसिटिव - एक्सन या डायक्रिटिक्स को ध्यान में रखते हुए, दूसरे शब्दों में, 'a' को 'equal' के बराबर नहीं माना जाता है।

SQL सर्वर स्थापित करते समय यह Collation डिफ़ॉल्ट रूप से Collation था।

क्या विकल्प हैं?

• _KS - हीरागाना और कटकाना के जापानी पात्रों को ध्यान में रखते हुए, यदि विकल्प का चयन नहीं किया जाता है, तो SQL सर्वर हीरागाना और कटकाना के चित्रलिपि की व्याख्या करेगा।
• _WS - वर्णों की चौड़ाई को ध्यान में रखते हुए, यदि पैरामीटर का चयन नहीं किया जाता है, तो "टेक्स्ट" और "टी एक्सटी" को एक ही रेखा माना जाता है।
• _VSS - जापानी में वर्तनी विकल्प चुनने के संकेतों को ध्यान में रखते हुए, 2017 संस्करण से दिखाई दिया।
• _UTF8 - आपको UTF8 में डेटा स्टोर करने की अनुमति देता है।

डेटाबेस में सभी पाठ फ़ील्ड NVARCHAR का उपयोग करते थे।
यह पता चला है कि, चूंकि मौजूदा कॉलेलेशन ने जापानी वर्णों की वर्तनी और वर्ण चौड़ाई में अंतर को नजरअंदाज कर दिया था, इसलिए SQL सर्वर ने तार की तुलना उसी तरह से नहीं की जिस तरह से ऑपरेटिंग सिस्टम ने किया, जिससे समस्या पैदा हुई, अर्थात। उपयोगकर्ता फ़ोल्डर्स बना सकता है, उन्हें सिंक्रनाइज़ेशन के लिए सिस्टम में नहीं जोड़ सकता है। फ़ाइल नामों की तुलना करते समय बाद में वही बात होगी।

हमने इस समस्या को हल करने और Collation को बदलने के बारे में सोचना शुरू किया।

टकराव को कई स्तरों पर सेट किया जा सकता है:

• SQL सर्वर इंस्टेंस
• डेटाबेस
• तालिका
• मैदान

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

ऐसी स्थिति में क्या विकल्प हैं जहां यह स्पष्ट है कि Collation को सही तरीके से नहीं चुना गया है?

1. DB स्तर पर परिवर्तन बदलें;
2. फ़ील्ड स्तर पर परिवर्तन बदलें (हमारे मामले में, पूरी तालिका के लिए बदलने का कोई मतलब नहीं था);
3. Varbinary फ़ील्ड जोड़ें, जिसमें फ़ोल्डर के नाम के साथ फ़ील्ड से डुप्लिकेट लिखने के लिए, और तुलना के लिए इसका उपयोग करें;
4. उपयोगकर्ताओं को बताएं कि निर्देशिका नामों में वर्णों के समर्थन पर प्रतिबंध हैं।

पहला विकल्प - डेटाबेस स्तर पर Collation बदलना - सबसे कठिन है। डेटाबेस के मामले में, डेटाबेस को फिर से बनाना और वहां डेटा पुनः लोड करना आवश्यक होगा। चूंकि सिस्टम ने 24/7 काम किया, इसलिए इस विकल्प को तुरंत अस्वीकार कर दिया गया।

फ़ील्ड को बदलने के बारे में दूसरा विकल्प: इसे लागू करने का सबसे आसान विकल्प वांछित Collation के साथ एक फ़ील्ड जोड़ना और वहां डेटा स्थानांतरित करना है। लेकिन फिर इस फ़ील्ड के साथ काम करने वाले डेटाबेस में कोड को बदलना आवश्यक होगा, और डेटाबेस में बहुत सारे कोड थे।

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

इस मामले में चौथा विकल्प सबसे सरल था, क्योंकि उपयोगकर्ताओं की कुल संख्या कई मिलियन थी, और केवल 50 में समस्या थी। हालांकि, अगर जापान में सक्रिय रूप से आवेदन का उपयोग किया गया था, तो यह समाधान बहुत कम उपयोग का होगा।

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

Collation चुनने का सबसे अच्छा विकल्प आपकी एप्लिकेशन आवश्यकताओं पर आधारित है। यदि आप चाहते हैं कि SQL सर्वर OS की तरह स्ट्रिंग की तुलना करे, तो निश्चित रूप से Collation डिफ़ॉल्ट रूप से गलत है। दुर्भाग्य से, इस तरह की बारीकियों को एक प्रणाली को डिजाइन करते समय एक परियोजना की शुरुआत में शायद ही कभी दिखाई देता है, लेकिन, उम्मीद है कि लेख को पढ़ने के बाद, आप वर्णित स्थिति को याद करेंगे और खुद को ऐसे रैक पर कदम न रखें।

उपयोगी सहयोग संसाधन:
https://docs.microsoft.com/en-us/sql/relational-databases/collations/collation-and-unicode-support?view=sql-server-2017
https://www.red-gate.com/simple-talk/sql/sql-development/questions-sql-server-collations-shy-ask/
https://www.virtual-dba.com/sql-server-collation/