Myślę, że pytanie, jak stwierdzono (z dnia 2015-04-20, „Które sortowanie [...]”) nie jest tym, co należy rozumieć, biorąc pod uwagę, że przyjęta odpowiedź mówi raczej o kodowaniu niż sortowaniu. Pozwól, że odpowiem na zadane pytanie, a nie na zamierzone, tylko dlatego, że uważam, że jest interesujące :-)
Wikipedia mówi „Sortowanie jest zbiorem pisemnych informacji w standardowym porządku”. W informatyce zestawienie przyjęło znaczenie „specyfikacji takiego zamówienia”. Innymi słowy, zestawienie jest (lub implikuje) definicją trójstronnej funkcji porównawczej.
Myślę, że krótka odpowiedź brzmi „zdecydowanie może”. Przynajmniej znam następujące shenanigany:
#!/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.strxfrmto funkcja Returns a string that behaves for cmp locale-aware, która koduje ciąg znaków tak, że standardowe porównanie leksykograficzne bajt po bajcie z innym ciągiem kodowanym podobnie daje taki sam wynik jak porównywanie ciągów zgodnie z funkcją sortowania określoną przez ustawienia regionalne.
Kilka uwag: w da_DK.utf8ciągu łańcuch ouüöjest sortowany. W de_DE.utf8ciągu ciąg oöuüjest sortowany. Zwróć uwagę, że len(long_form) == 38i 38> 13. (Długość wynosi również 38 cali de_DE.utf8).
Jeśli baza danych ma indeks w jakimś polu ciągu, posortowanym według da_DK.utf8, może wewnętrznie robić coś takiego strxfrm, aby uzyskać proste porównanie. (Z drugiej strony dyski działają wolno. Indeksowanie na podstawie bardziej zwartej reprezentacji może być szybsze, jeśli wyższy koszt porównania na znak jest więcej niż kompensowany przez porównanie mniejszej liczby znaków.)
Pytasz „Czy zestawienie ma jakiś wpływ na szybkość zapytania?”, Na co jestem prawie pewien, że odpowiedź brzmi „tak”: zestawienie „C” (inaczej „POSIX”) po prostu porównuje wartości punktowe kodu Unicode, podczas gdy duński ( da_DK.utf8) i lokalizacje niemieckie ( de_DE.utf8) robią coś trudniejszego. Będzie to miało pewien wpływ na szybkość zapytań, choć podejrzewam, że nie warto się o to martwić.
„Czy rozmiar tabeli zmienia się w zależności od sortowania?” - Mogę sobie wyobrazić posiadanie indeksu według jednego zestawienia i innego indeksu według innego zestawienia, lub tylko jednego z takich dwóch wskaźników, z zastosowaną jakąś strxfrmtransformacją. W tym hipotetycznym scenariuszu, jeśli istnieją dwa zestawienia o różnych charakterystykach wielkości, odpowiedź brzmi „tak”.
„który byłby zalecanym zestawieniem?” - To zależy od tego, dlaczego trzeba sortować ciągi. Gdyby tylko miał jakiś kanoniczny sposób porządkowania łańcuchów, prawdopodobnie wybrałbym „C”. Jeśli ma on przedstawiać użytkownikom dane w uporządkowanej kolejności zgodnie z oczekiwaniami człowieka, a oczekiwania te są kształtowane przez ich kulturę, a chcesz, aby baza danych (a nie jakaś inna warstwa) przeprowadzała sortowanie, być może powinieneś zbudować jeden indeks na sortowanie , czyli co najmniej jeden według da_DK.utf8Duńczyków i jeden według de_DE.utf8Niemców. Myślę jednak, że może to szybko stać się dość duże.
Wszystko to w dużym stopniu zależy od wewnętrznego działania bazy danych; Myślę, że wykracza to znacznie poza „znormalizowany” (lol!) SQL. Jak zawsze, zajrzyj do dokumentacji konkretnego systemu baz danych.