Требуется сопоставление без учета регистра, где ss != ß

Для определенного столбца в базе данных, работающей на SQL Server Express 2012, мне нужна сортировка, при которой ss и ß не считаются одинаковыми при сравнении строк. Также ä и ae, ö и oe и ü и ue следует считать разными соответственно. Latin1_General_CI_AS обеспечивает последнее, но ss и ß не различаются. То есть WHERE ThatColumn = 'Fass' даст как Fass, так и Faß.

Я бы просто придерживался BIN/BIN2, но мне нужна нечувствительность к регистру. Если больше ничего не работает, мне придется использовать Latin1_General_BIN/Latin1_General_BIN2 и самому убедиться, что все в верхнем или нижнем регистре. Это означало бы больше работы, так как мне также нужно иметь возможность получить версию с правильным регистром.

Но если есть сопоставление, которое делает то, что мне нужно, пожалуйста, дайте мне знать. Заранее спасибо!

Обновление: дополнительная информация о требованиях: база данных содержит личные имена из устаревшей системы, которая поддерживала только символы ASCII. То есть такие имена, как Мюллер и Фасс, сохраняются как Мюллер и Фасс. В новой системе у пользователя будет возможность переименовывать этих людей, например. переименовать «Мюллер» в «Мюллер». Чтобы найти объекты, которые нужно переименовать, мне нужно найти строки, содержащие, например. "Фасс". Но сейчас запрос также возвращает «Faß», а это не то, что мне нужно. Мне все еще нужна / нужна нечувствительность к регистру, поскольку пользователь должен иметь возможность искать «fass» и по-прежнему получать «Fass».

В системе есть еще что-то, но я могу определенно сказать, что мне нужно различать ss и ß, ä и ae и т. д.


person Andre Loker    schedule 27.04.2012    source источник
comment
Это кажется странным требованием. Любая причина? Можете ли вы уточнить это - это просто ss и ß или есть другие лигатуры / специальные, которые нужно специально обрабатывать?   -  person Ben    schedule 27.04.2012
comment
Я обновил вопрос. Мне определенно нужно уметь различать ss и ß.   -  person Andre Loker    schedule 27.04.2012


Ответы (1)


Сопоставление SQL_Latin1_General_CP1_CI_AS считает, что «ss» отличается от «ß», поэтому оно может работать для вас. Это устаревшее сопоставление, поэтому оно может привести к несовместимости с операционными системами и платформами приложений. У него могут быть и другие особенности, о которых я не знаю.

Несколько лет назад я набросал неуклюжий обходной путь для подобной проблемы, и вы можете взглянуть на него здесь. (Нажмите на вкладку «Временные решения (1)».) В этом случае проблема заключалась в уникальности в ключевом столбце, а не в результатах сравнения строк, чтобы применить его в вашей ситуации (и сравнить два столбца, чтобы выполнить сравнение одной строки) может оказаться невыполнимым.

person Steve Kass    schedule 27.04.2012
comment
Нет, извините, SQL_Latin1_General_CP1_CI_AS не работает. Вот как я это проверял: pastebin.com/nEKJk7bX - person Andre Loker; 27.04.2012
comment
Андре, я не верю, что твой тест адекватен. Я подозреваю, что сопоставление базы данных автоматически применяется к константной строке в вашем примере pastebin, и сравнение не выполняется при сопоставлении столбцов. См. этот пример: sqlfiddle.com/#!3/d5344/6 - person Steve Kass; 28.04.2012
comment
Ага! Теперь я вижу, что вы используете nvarchar. Я думаю, что сопоставления SQL, определяющие кодовую страницу, вам не подойдут. Если вы должны использовать nvarchar, я думаю, вам может не повезти. - person Steve Kass; 28.04.2012
comment
Вы правы, с varchar это работает. Мне нужно проверить, смогу ли я обойтись без varchar в этом особом случае. Приложение не будет использоваться на международном уровне. - person Andre Loker; 28.04.2012
comment
Я приму этот ответ. Хотя необходимость вернуться к varchar, конечно, не так уж и велика, но нам пока это подойдет. - person Andre Loker; 03.05.2012