И ты бы, Ваня, у них был Vanä - Узором созвездий по мантии ночи
19.08.2014, Вторник
10:03:00 - И ты бы, Ваня, у них был Vanä
Внезапно наткнулся на то, что MySQL при COLLATE utf8_general_ci (или utf8_unicode_ci) не различает не только большие и маленькие буквы (что как раз нужно, и суффиксу _ci соответствует), но также не отличает буквы с диакритикой от их "обычных" аналогов, в частности 'Melkor' == 'Melkör' и 'kossak' == 'KOŞŞAK'.
Если задать COLLATE utf8_bin -- то теряем и регистронезависимость, что не устраивает.
Погугли немного, поискал на http://stackoverflow.com -- похоже, решение на уровне базы данных отсутствует, т.е. придётся включать utf8_bin, а регистронезависимость реализовывать на уровне приложения.
This entry was originally posted at http://arilou.dreamwidth.org/946980.html. Please comment there using OpenID.
Нельзя хранить какую-нибудь нормальную форму в качестве уникального ключа? А то при независимой реализации ты забудешь какой-нибудь вариант диакритики и огребешь.
Никакой "зависимости от языка" сделать не можно.
Это ник игрока. Язык игрока нам не известен (известно, какая локализация клиента, но это ведь не то же самое).
Хотелось уникальный индекс. Т.е. база давно есть, в ней 2 миллиона записей. Начав смотреть один из багов, обнаружил, что индекс по никам неуникальный. Пошёл смотреть, а есть ли дубликаты ников -- нашёл с полсотни, большинство пар различались диакритикой (наличием/отсутствием) в некоторых буквах, типа примеров самом в посте.
Мне было любопытно, смогу ли я сделать уникальный индекс или придётся обойтись проверками на уровне приложения (они есть, но при том некоторый думы попали в базу в обход них).
Ну т.е. я уже описал ситуацию. Позже уточню, чего в итоге хочется.
Но если диакритику отрывать -- придётся что-то делать с имеющимися дублями.
Поскольку некоторые запросы в сервере грустят, когда получают более одной записи в ответе. Если решить, что делать с дублями, вариант accent insensitive collation меня-то вполне устроит.