Архитектура SQL Server для конкретной задачи - полнотекстовый поиск - с полным объединением - PullRequest
0 голосов
/ 15 августа 2011

Я создаю приложение, которое ищет резюме кандидатов. Мне нужно использовать полнотекстовый поиск в приложении, так как записей много, а поле резюме довольно большое. Проблема в том, что для расширенного поиска у меня есть другая таблица RelocationItems, в которой перечислены почтовые индексы, состояния и т. Д. Для предпочтений перемещения кандидатов, и которая связана с кандидатом в таблице RelocationItems. Проблема в том, что иногда у кандидата не будет RelocationItems, иногда у него будет один, а иногда у них будет больше одного. Итак, достаточно просто, я создал представление, которое использует полное внешнее объединение, и затем могу выбрать, используя DISTINCT дляандидата, чтобы найти кандидатов, которые мне нужны, которые будут перемещены в определенную область на основе критериев поиска.

Большая проблема с этим представлением, поскольку, поскольку он использует и Full Join, я не могу сейчас использовать полнотекстовый поиск! (очевидно, потому что мое поле полнотекстового индекса теперь не является уникальным ненулевым полем)

И в моей хранимой процедуре есть слово CONTAINS, поэтому она даже не скомпилируется.

Должен ли я: - Создать новую таблицу на основе представления? (а затем создайте другое поле идентификатора индекса) Сделать что-то для хранения элементов перемещения в таблице кандидатов (может быть, поле XML)? (Я не думаю, что вы можете сохранить параметр табличного значения в 2008 году, не так ли?) - Есть ли какой-то союз таблиц (запросов)? (Запустите поиск по таблице «Кандидаты», а затем по таблице «Перемещение», а затем объедините или объедините)?

Спасибо за любые предложения о том, как лучше обойти эту проблему !!!

1 Ответ

0 голосов
/ 15 августа 2011

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

Уже потенциальная проблема - лучше выбрать подпункт с.

Правильно настроенный запрос не вызовет проблем - не используйте объединение, перейдите на подвыбор и существует.

...