проблема с IN и LIKE в SQL, когда аргументы содержат специальные символы для языка

Question

У меня есть такая таблица ключей (MS SQL):

• KeyGuid Qualifier PrimitiveKey
• DA7E4E27-FDE5-4D43-A365-8A789164A816 tit kirkäna
• EED58875-FE41-4A18-A93C-A44AA62CEEEE htit kirkänbh
• A0EB795E-EE23-4990-BAB9-897C93C70CE3 htit kirkänah
• F7F4632B-AC82-4DEB-B966-BBA8EF4D2C9E tit kirkänb
• C0EB795E-EE23-4990-BAB9-897C93C70CE3 nam kirkänas
• E2F4632B-AC82-4DEB-B966-BBA8EF4D2C9E nam kirkänbs
• A222795E-EE23-4990-BAB9-897C93C70CE3 tit kirkacb
• B333632B-AC82-4DEB-B966-BBA8EF4D2C9E, кирка, синица
• 1222795E-EE23-4990-BAB9-897C93C70C81 htit kirkacbh
• E533632B-AC82-4DEB-B966-BBA8EF4D2C82 htit kirkacah

Этот простейший запрос правильно возвращает все соответствующие записи:

select * from KeyWord where PrimitiveKey like 'kirkän%'

• DA7E4E27-FDE5-4D43-A365-8A789164A816 tit kirkäna
• EED58875-FE41-4A18-A93C-A44AA62CEEEE htit kirkänbh
• A0EB795E-EE23-4990-BAB9-897C93C70CE3 htit kirkänah
• F7F4632B-AC82-4DEB-B966-BBA8EF4D2C9E tit kirkänb
• C0EB795E-EE23-4990-BAB9-897C93C70CE3 nam kirkänas
• E2F4632B-AC82-4DEB-B966-BBA8EF4D2C9E nam kirkänbs

Я использую такой запрос, чтобы ограничить результаты для соответствия определителям:

select * from KeyWord where Qualifier IN ('tit', 'htit') and PrimitiveKey Like 'kirkac%'

, который отлично работает:

• A222795E-EE23-4990-BAB9-897C93C70CE3 tit kirkacb
• B333632B-AC82-4DEB-B966-BBA8EF4D2C9E синица Киркака
• 1222795E-EE23-4990-BAB9-897C93C70C81 htit kirkacbh
• E533632B-AC82-4DEB-B966-BBA8EF4D2C82 htit kirkacah

Однако, когда фраза содержит специальный символ, такой как ä, она не возвращает результатов:

select * from KeyWord where Qualifier IN ('tit', 'htit') and PrimitiveKey Like 'kirkän%'

и не имеет таких ограничителей, как это:

select * from KeyWord where (Qualifier = 'tit' OR Qualifier = 'htit') and PrimitiveKey Like 'kirkän%'

Однако это работает так:

select * from KeyWord where (Qualifier like 'tit' OR Qualifier like 'htit') PrimitiveKey Like 'kirkän%'

• DA7E4E27-FDE5-4D43-A365-8A789164A816 tit kirkäna
• EED58875-FE41-4A18-A93C-A44AA62CEEEE htit Kirkänbh
• A0EB795E-EE23-4990-BAB9-897C93C70CE3 htit kirkänah
• F7F4632B-AC82-4DEB-B966-BBA8EF4D2C9E tit kirkänb

Что не так с подходом IN?

Answer 1

взгляните на http://msdn.microsoft.com/en-us/library/ms179886.aspx

в основном операнд LIKE имеет его: собственную сортировку, которая переопределяет настройки сервера и столбца. Однако я не смог выяснить, где или если есть способ изменить эту настройку. Вышеприведенную статью довольно сложно прочитать, но я думаю, что самое подробное объяснение находится внизу.

Answer 2

Возможно, вам нужно использовать типы данных, совместимые с юникодом. Объявляя столбец PrimitiveKey как nvarchar, попробуйте добавить префикс строки, которую вы хотите сопоставить, с 'N' следующим образом: выберите * из ключевого слова, где (квалификатор, например, «tit», ИЛИ квалификатор, например, «htit») и PrimitiveKey, как N'kirkän% '.

Answer 3

Я провел дополнительное расследование по этой проблеме. Вот что я нашел.

A. Проблемный запрос фактически возвращает результаты, но содержит только «ae»:

select * from KeyWord where Qualifier IN ('tit', 'htit') and PrimitiveKey Like 'kirkän%'

возвращает, например, 'kirkaeni'.

B. Если в запрос включен еще один% (например, «ki% rkän%»), результаты включают ожидаемые! (это странно) (но и те, которые не нужны, конечно же, соответствуют другим%).

C. Я попытался воспроизвести проблему - создавая простую БД только с двумя таблицами (у одной с «kirk» есть внешний ключ к другой), я использовал запросы, создающие проблемную БД, а также те, которые создают таблицы, у меня есть установить такое же сопоставление (German_PhoneBook_CI_AI) + я создал индексы, как в проблемной БД. Однако проблема не возникла, поэтому я пока не могу воспроизвести ее.

Есть какие-нибудь новые идеи с этими симптомами?

Answer 4

Я думаю, вам стоит взглянуть на Полнотекстовый поиск .Я знаю, что изменение сортировки здесь поможет, как говорит Нил, но вы можете получить некоторую выгоду от использования FTS в зависимости от того, насколько масштабируемой должна быть ваша реализация.

Answer 5

Это, вероятно, лучше всего обрабатывать с помощью определенной настройки сортировки, которая справляется с символами для конкретного языка.

Вот статья о сопоставлении SQL Server, которая может помочь: http://msdn.microsoft.com/en-us/library/aa174903(SQL.80).aspx