आपके कॉलम का डेटा एक वर्ण सेट का उपयोग करके संग्रहीत किया जाता है। इस मामले में यह utf8 प्रतीत होता है।
जब आप उन स्तंभों पर काम करते हैं (उदाहरण के लिए, समानता की तुलना या आदेश देना), तो MySQL एक संयोजन का उपयोग करता है। प्रत्येक कॉलम में एक डिफ़ॉल्ट संयोजन होता है, जो इसे तालिका के डिफ़ॉल्ट संयोजन से प्राप्त होता है।
इंडेक्स में कॉलम का डिफ़ॉल्ट कोलेशन बेक किया हुआ होता है ताकि वे कुशलता से काम कर सकें।
आप एक समानता तुलना कर सकते हैं जो संयोजन द्वारा योग्य है। उदाहरण के लिए, JOIN . में आप निर्दिष्ट कर सकते हैं
ON (turkish.village_name COLLATE utf8_general_ci) = euro.village_name
या शायद
ON turkish.village_name = (euro.village_name COLLATE utf8_turkish_ci)
इससे आपको अपनी तालिका में बदलाव करने की आवश्यकता के बिना आपके अवैध मिश्रण को समाप्त करना चाहिए। यह आपको उस डेटाबेस परिवर्तन से बचने में मदद कर सकता है जिसके बारे में आप पूछ रहे हैं। लेकिन सावधान रहें, COLLATE . का उपयोग करके क्वालीफायर इंडेक्स के उपयोग को हरा सकता है। यदि आपके पास एक बड़ी तालिका है और आप प्रदर्शन के लिए अनुक्रमणिका पर निर्भर हैं, तो यह अनुपयोगी हो सकता है।
तो, यदि आप डिफ़ॉल्ट मिलान को बदलने के लिए अपनी तालिकाएँ बदलते हैं तो क्या होगा?
- आपका डेटा नहीं बदलेगा (जब तक कि आप वर्ण सेट को भी नहीं बदलते)। यह अच्छा है।
- कोई भी अनुक्रमणिका जिसमें कॉलेशन वाले कॉलम शामिल हैं, उन्हें फिर से जनरेट किया जाएगा।
- आपकी तुलना और आदेश बदल सकते हैं। मैं तुर्की नहीं जानता, इसलिए मैं आपको नहीं बता सकता कि क्या टूट सकता है। लेकिन, उदाहरण के लिए, स्पैनिश में N . अक्षर और Ñ वह सामान नहीं है। एन Ñ . से पहले आता है एक स्पेनिश संयोजन में, लेकिन सामान्य संयोजन में उन्हें समान माना जाता है। तुर्की वर्णमाला का कुछ पहलू हो सकता है जो समान कार्य करता है, इसलिए आपका
ORDER BYपरिणाम गलत होंगे।
लेकिन, आप एक COLLATE . निर्दिष्ट करके इसे ठीक कर सकते हैं आपके ORDER BY . में संशोधक खंड।
ORDER BY (euro.village_name COLLATE utf8_turkish_ci)
