Dwie różne metody porównywania napisów, utf_unicode vs general_ci Opcje

[markonix]

Mam duży portal wielojęzyczny i oczywiście kodowanie UTF-8.
Niestety w MySql ten wybór nie jest taki oczywisty bo mamy go wiele odmian.

Do wyboru są wg mnie dwa:
utf8_unicode_ci i utf8_general_ci

Ten pierwszy jest lepszy jeżeli chodzi np. o sortowanie z polskimi znakami (osoby typu Łukasz nie lądują na końcu) ale w jakimś tam stopniu jest wolniejszy.
Zastanawiam się czy nie byłoby ciekawą ideą aby stosować te powyższe kodowania zamiennie - unicode w przypadku tabel z nazwami własnymi, a general tylko do tabel "zamkniętych" (tabele ustawień, wyniki, relacje, po prostu tabele gdzie są tylko liczby i krótkie stringi po angielsku).

Czy taka zabawa jest warta świeczki i nie wywoła błędu z "Illegal mix of collations"?
Lepiej sobie darować i lecieć w jednym?
Jeżeli jednak mieszać to jakie powinno być kodowanie główne (całej bazy - chyba, że to nie ma większego znaczenia i jest tylko po prostu domyślnym kodowaniem dla tabel w bazie).

Ten post edytował markonix 30.07.2012, 14:57:24

[Crozin]

1. Jeżeli dla danej kolumny nie będziesz w ogóle stosować porównań (pamiętaj, że dotyczy to również sortowań), będziesz przechowywać tam jedynie znaki łacińskie bądź będziesz wykonywać dokładne porównania (np. dla kolumny z slugiem nazwy użytkownika, bądź kluczem jakiejś opcji konfiguracyjnej) możesz korzystać z binarnej metody porównywania znaków (utf8_bin).
2. "Ł" na końcu listy przy utf8_unicode_ci to bug MySQL-a, którego chyba nigdy nie poprawią albo w ogóle nie chcą poprawić - nie pamiętam, wiem że jest zgłoszone na bugtracku MySQLa.
3. Pamiętaj, że metoda porównywania znaków może zostać określona na poziomie zapytania SQL:

[SQL] pobierz, plaintext 
SELECT ... ORDER BY col_name COLLATE utf8_unicode_ci ...;
[SQL] pobierz, plaintext 

I nie będzie to miało żadnego wpływu na prędkość wykonywania zapytania.