Мне нужно выяснить, как я могу искать текст на японском языке с помощью полнотекстового поиска в SQL Server 2014 или более поздней версии.

Question

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

У меня есть зрелая база данных SQL Server 2014, где все символьные столбцы являются nvarchar. Мое приложение - приложение WPF. NET 4.6- +, и оно удобно пишет и читает текст на любом языке, так что с этого момента все хорошо. Я использую полнотекстовый поиск MS для поиска текста в столбцах nvarchar (max), и это прекрасно работает почти со всеми языками, и я понимаю, как это работает за кулисами. До недавнего времени мне не нужно было искать японский текст, который не работает.

Я изо всех сил пытаюсь найти достаточно информации по этому вопросу, но я решил, что проблемы могут быть связаны с границами слов, которые японцы текст, кажется, не так много. Похоже, он хранит большую часть своего текста в одну большую длинную строку и объединяет то, что мы знаем как слова, и я понимаю, почему SQL Сервер будет бороться с этим. Я пробовал '' текст, чтобы найти '' подстановочные знаки с CONTAINS / CONTAINSTABLE, но это все еще не работает. Использование LIKE является опцией, но, возможно, с 20 000 000 строк, о которых не может быть и речи.

Я уже некоторое время работаю с SQL Server и знаю это очень хорошо, особенно с точки зрения настройки производительности. так что я, конечно, не новичок в этом. Кто-нибудь еще сталкивался с этим и нашел ли ты решение для этого? Конечно, SQL Сервер не может просто исключить Японию.

Answer 1

Проблема с реализацией Microsoft полнотекстового поиска заключается в том, что он, по сути, допускает только один язык на полнотекстовый индекс , и этот язык необходимо указать в определении индекса, если он отличается от значения по умолчанию язык экземпляра SQL Server. Другое ограничение заключается в том, что у вас может быть только один полнотекстовый индекс на таблицу или индексированное представление.

Существует несколько обходных путей в зависимости от архитектуры и сложности вашей системы. Например, вы можете создать несколько таблиц, по одной на язык, в которой будет храниться проиндексированный контент. К сожалению, ваше приложение должно каким-то образом «понять», куда и куда идет запись, или ваши пользователи будут вынуждены устанавливать правильный язык каждый раз, когда вводят новые данные.

Кроме того, весь текст может быть сохранен. в той же таблице, но вместо этого вы должны создать несколько индексированных представлений, каждое из которых предоставляет только подмножество или записи на одном языке, а затем создавать полнотекстовые индексы для этих представлений. Опять же, проблема идентификации языка остается.

Конечно, ваше приложение может попытаться определить текущую раскладку клавиатуры, когда пользователь вводит текст (не уверен, возможно ли это в WPF, но я сделал это в WinForms ). Это, вероятно, не будет работать с копированием-вставкой и загруженными документами, если ваша система хранит их.

По моему опыту, наиболее жизнеспособное решение - это позволить вашим клиентам самим указывать язык FTS при установке вашего приложения. , Если ваша аудитория глобальная, вы не можете охватить каждый язык из коробки. К счастью, из того, что я видел, текст Engli sh ищется более или менее надежно, независимо от языка индекса.