मुझे लगता है कि जैसा कि कहा गया है (2015-04-20, "कौन सा टकराव [...]") सवाल का मतलब नहीं है, यह देखते हुए कि स्वीकृत उत्तर टकराव के बजाय एन्कोडिंग के बारे में बात करता है। मुझे बताए गए प्रश्न का उत्तर केवल एक उद्देश्य के बजाय देना चाहिए, क्योंकि मुझे लगता है कि यह दिलचस्प है :-)
विकिपीडिया का कहना है कि "Collation एक मानक क्रम में लिखित जानकारी का संयोजन है"। कंप्यूटिंग में, टकराव "इस तरह के एक आदेश की एक विनिर्देश" के अर्थ पर लिया गया है। दूसरे शब्दों में, एक टकराव एक तीन-तरफा तुलनात्मक फ़ंक्शन की परिभाषा है।
मुझे लगता है कि संक्षिप्त उत्तर "निश्चित रूप से हो सकता है"। कम से कम मुझे निम्नलिखित शेंनिगों के बारे में पता है:
#!/usr/bin/python
name = u"Jonas K\xf6lker" # \xf6 is o-umlaut
enc = name.encode('utf-8')
assert len(name) == 12 # \xf6 is one character
assert len(enc) == 13 # but two bytes in utf-8
import locale
locale.setlocale(locale.LC_COLLATE, "da_DK.utf8") # works on my machine
long_form = locale.strxfrm(enc)
assert len(long_form) == 38
locale.strxfrmएक फ़ंक्शन है Returns a string that behaves for cmp locale-aware, जो है, यह एक स्ट्रिंग को एन्कोड करता है जैसे कि एक अन्य स्ट्रिंग के खिलाफ बाइट-बाइट मानक लेक्सिकोग्राफ़िक तुलना में एन्कोडेड उसी तरह से परिणाम देगा जैसे कि लोकेल द्वारा निर्दिष्ट टकराव फ़ंक्शन के अनुसार स्ट्रिंग्स की तुलना करना।
कुछ अवलोकनों में: da_DK.utf8स्ट्रिंग ouüöको क्रमबद्ध किया गया है। में de_DE.utf8, स्ट्रिंग oöuüक्रमबद्ध है। ध्यान दें कि len(long_form) == 38और 38> 13. (लंबाई भी 38 इंच है de_DE.utf8।)
अपने डेटाबेस कुछ स्ट्रिंग मैदान पर एक सूचकांक है, के अनुसार collated da_DK.utf8, यह हो सकता है आंतरिक रूप से की तरह कुछ कर रही strxfrmहै, ताकि एक सरल तुलना करने के लिए में। (दूसरी ओर, डिस्क धीमी हैं। यह अधिक कॉम्पैक्ट प्रतिनिधित्व के आधार पर अनुक्रमणिका के लिए तेज़ हो सकता है, अगर कम वर्णों की तुलना में अधिक प्रति-वर्ण तुलना लागत ऑफसेट से अधिक है।)
आप पूछते हैं कि "क्या एक कोलाजेशन का क्वेरी गति पर कोई प्रभाव पड़ता है?", जिसके बारे में मुझे पूरा यकीन है कि इसका उत्तर हां है: "C" (उर्फ "POSIX") कोलेशन केवल यूनिकोड कोड पॉइंट वैल्यू की तुलना करता है, जबकि डेनिश ( da_DK.utf8) और जर्मन ( de_DE.utf8) स्थान कुछ अधिक मुश्किल काम करते हैं। इससे क्वेरी की गति पर कुछ प्रभाव पड़ेगा, हालांकि मुझे संदेह है कि यह चिंता करने लायक नहीं होगा।
"क्या टकराव के आधार पर तालिका का आकार बदलता है?" - मैं कल्पना कर सकता हूं कि एक कोलाज के अनुसार एक इंडेक्स हो सकता है और दूसरे कॉलेशन के अनुसार एक अलग इंडेक्स हो सकता है, या ऐसे ही दो सूचकांकों में से एक, कुछ strxfrm- कुछ परिवर्तन के साथ लागू किया जा सकता है। उस काल्पनिक परिदृश्य में, यदि विभिन्न आकार विशेषताओं के साथ दो टकराव होते हैं, तो इसका उत्तर हां में है।
"जो अनुशंसित टकराव होगा?" - यह इस बात पर निर्भर करता है कि आपको स्ट्रिंग्स को क्रमबद्ध करने की आवश्यकता क्यों होगी। यदि यह केवल तार के आदेश के कुछ विहित तरीका है, तो मैं शायद "सी" के साथ जाऊंगा। यदि यह मानव की अपेक्षाओं के अनुसार छंटनी क्रम में उपयोगकर्ताओं को डेटा प्रस्तुत करने के लिए है, और उन उम्मीदों को उनकी संस्कृति द्वारा आकार दिया गया है, और आप चाहते हैं कि डेटाबेस (और कुछ परत नहीं) सॉर्टिंग करने के लिए, शायद आपको प्रति कोलाज एक सूचकांक बनाना चाहिए , यानी कम से कम da_DK.utf8डेन्स के लिए एक और de_DE.utf8जर्मनों के अनुसार एक । मुझे लगता है कि यह काफी जल्दी काफी बड़ा हो सकता है, हालांकि।
यह सब आपके डेटाबेस के आंतरिक कामकाज पर अत्यधिक निर्भर है; मुझे लगता है कि यह "मानकीकृत" (योग्य!) एसक्यूएल से परे है। हमेशा की तरह, अपने विशिष्ट डेटाबेस सिस्टम के प्रलेखन से परामर्श करें।