Witajcie,

temat collation w MySQL jest wałkowany na wszystkie strony, a mimo wszystko nie znalazłem odpowiedzi na mój problem.

Chcę stworzyć tabelę, w której przechowywane będą słowa w różnych językach. Zależy mi na prawidłowym sortowaniu i dokładnym wyszukiwaniu. Pod lupę wziąłem cztery najpopularniejsze u nas kodowania:

1. utf8_general_ci
   Odpada, bo dla niego Ą = A, Ó = O itd. Nici z wyszukiwania i dokładnego sortowania.
2. utf8_unicode_ci
   To samo co w general.
3. utf8_polish_ci
   Wszystko gra, ale tylko dla polskiego języka.
4. utf8_bin
   Wyszukiwanie działa prawidłowo, ale sortowanie stawia znaki narodowe za łacińskimi.

Czy istnieje w ogóle rozwiązanie łączące w sobie wszystkie cechy, których poszukuję?

Zobacz czy sortuje z utf-16 ponad 65k mozliwych kombinacji więc raczej nic się nie będzie gryzło.
Ewentualnie wpadłem na pomysł (jeśli wrzucasz słowa "ręcznie" przez plik php) to podczas wrzucania zamieniać znaki diaktryczne w jakiś ciąg liczb (np. ą zamieni się na 123) a przy wyswietlaniu znów zmiana (z 123 na ą). Tak jak pisałem właśnie coś takiego wymysliłem i w mojej głowie powinno to działać, ale wiesz jak jest Chociaż nie wiem wtedy jak z sortowaniem. No i oczywiscie nie jest to najwydajniejsze.

Wydaje mi się że rozwiązania nie ma.
Albo chcesz WSZYSTKIE alfabety, albo chcesz polski.
Jeśli wszystkie, to nie będą posortowane (bo co jest pierwsze: ą czy ä, <ruskie f> czy f?).
Musisz raczej napisać własną funkcję, co nie będzie łatwe, bo musisz każdy alfabet dodać ręcznie a tych jest dużo.

Inne rozwiązanie jakie widzę to:
trzymasz dane w utf8_unicode_ci albo utf8_bin (nie pamiętam)
podczas sortowanie sprawdzasz skąd jest użytkownik.
Na przykład użyszkodnik jest Polakiem, to w zapytaniu po ORDER dodajesz:
COLLATE utf8_polish_ci
Bo co nas obchodzę egipskie znaczki? Nasze słowa się dobrze sortują.

Zrobiłem test i wyszło na to, że utf8_general_ci i utf8_unicode_ci traktują a jako ą itd., ale jest jeden wyjątek. O dziwo L i Ł nie są traktowane jako zamienniki. Bardzo to dziwne.

Wydaje mi się, że masz rację, Timon27. Najlepiej dokładać collate do wszystkich zapytań SELECT, nie tylko tych z sortowaniem. Bo jak będę trzymał na przykład słownik w tabeli z utf8_unicode_ci i robił zwykłe SELECT, to dowiem się, że istnieją takie słowa jak KÓT, PIEŚ, ŁODZ i tak dalej:

[SQL] pobierz, plaintext 
SELECT count(*) FROM dictionary WHERE word = 'kót'
[SQL] pobierz, plaintext 

Takie zapytanie zwróci 1, bo potraktuje KÓT na równi z KOT.