Вопрос по SQL Server Yukon

[uniqueman]

Можно ли задать full text seach в новой версии Yukon как case sensitive?

В предыдущих версиях SQL Server такой поиск был строго case insensitive благодаря природе организации поиска (использование отдельного сервиса для индексирования и поиска и тому подобное).

Интергрирован ли full text search в новой версии полностью в ядро базы и позволяет ли новая версия проводить case sensitive поиск?

[8K]

Интергрирован ли full text search в новой версии полностью в ядро базы и позволяет ли новая версия проводить case sensitive поиск?

Я бы не рассчитывал на это. MS Search по-прежнему цветет и пахнет.

[uniqueman]

Уважаемый 8К,

Как правильно организовать работу full text search на SQL Server 2000. Каждый день с этим search какие то проблемы. Выполнил все по указаниям, поставил все как надо. Проходит день и опять что то сбивается и результаты выборок становятся неправильными.

Если нужны исходдные данные, то напишу с радостью. Запарился я уже с этим full text search.

[8K]

Ну, не то чтобы я разбирался, как оно там в SQL Server 2000 устроено (это вообще болото страшное, к тому же, я пришел уже после того, как его шипнули)...

Впрочем, помогу, чем смогу. Только вы проблему толком опишите, а то "поставил все, как надо, а оно не работает" звучит довольно расплывчато.

[uniqueman]

Впрочем, помогу, чем смогу. Только вы проблему толком опишите, а то "поставил все, как надо, а оно не работает" звучит довольно расплывчато.

Сейчас. Вот как обстоит дело.

Есть таблица TABLE. В ней два поля типа text настроены под full text search. Настроил индекс, сделал full population и поставил Change tracking with backgound indexing.

В базу льется информация примерно 10К в секунду. Мне надо обновлять индексы сразу же, именно поэтому выставил change tracking.

Каждую ночь из таблицы удаляются записи некоторые. Вопрос сразу. Надо ли после этого делать full population заново? Я сначала делал, потом по совету приветовцев перестал делать. Если надо, то надо ли после этого заново переустанавливать change tracking with background indexing?

Периодечески калатог входит в состояние Shutdown. Что это значит и почему происходит? После этого судя по всему никакого индексирования не происходит. Приходится делать Rebuild catalog чтобы опять вернутся в нормальное состояние

Сейчас допустим я пишу запрос

SELECT *
FROM TABLE
WHERE CONTAINS (*, 'full')

возвращаются записи как содержащие слово full так и НЕ содержащие этого слова. Как я проверяю? Я в коде просто создаю переменную типа string, присваиваю ей возвращенный результат и вызываю функцию find с параметром full. Возвращается -1, то бишь слово не найдено. Тогда для подтверждения я просто копирую текст который мне возвращатся в текстовый редактор и пытаюсь найти слово full там. Также не находит.

Какие параметры надо проверить, чтобы удостоверится что все настроено правильно? Гемор имею каждый день с FTS

Спасибо

[uniqueman]

и еще. Возможно ли как то настроить case sensitive full text search ?

[8K]

Возможно ли как то настроить case sensitive full text search ?

Нет.

[8K]

Каждую ночь из таблицы удаляются записи некоторые. Вопрос сразу. Надо ли после этого делать full population заново?

Если некоторые - то не надо. Индекс, правда, разбухает. Хотя при включенном change tracking - не должен. Ввиду асинхронности индексирования может влиять на результаты поиска (например, запись удалена, затем вставлена с тем же самым значением full-text key, но с другим содержимым full-text column - пока индекс не обновится, вы будете иногда получать эту запись, даже если она не удовлетворяет критерию поиска). Если значения full-text key не переиспользуются, то все нормально.

[8K]

пишу запрос

SELECT *
FROM TABLE
WHERE CONTAINS (*, 'full')

возвращаются записи как содержащие слово full так и НЕ содержащие этого слова. Как я проверяю? Я в коде просто создаю переменную типа string, присваиваю ей возвращенный результат и вызываю функцию find с параметром full. Возвращается -1, то бишь слово не найдено. Тогда для подтверждения я просто копирую текст который мне возвращатся в текстовый редактор и пытаюсь найти слово full там. Также не находит.

Вы сказали, что там две колонки зарегестрированы для индексирования. Вы в обеих колонках текст ищете? Вообще, этот изврат с find и тестовым редактором я не понимаю для чего нужен. LIKE '%full%' должно работать не хуже.

Убедитесь также, что эта "неправильная" запись не висит в sysfulltextnotify. Может, она просто еще не дошла до MS Search по какой-то причине. В принципе, можно посмотреть, что там в каталоге находится, но я не уверен, что эту программу вместе с сервером поставляют, да и даже если бы она была - затрахаешься ей правильные параметры передавать.

[uniqueman]

Если некоторые - то не надо. Индекс, правда, разбухает.

у меня данные хранятся в таблице только за последние пять дней. Следовательно кажду ночь удаляются записи которые старше пяти дней.

Удаляются примерно 4000 записей каждую ночь. Это "некоторые" или нет?

Ввиду асинхронности индексирования может влиять на результаты поиска (например, запись удалена, затем вставлена с тем же самым значением full-text key, но с другим содержимым full-text column - пока индекс не обновится, вы будете иногда получать эту запись, даже если она не удовлетворяет критерию поиска). Если значения full-text key не переиспользуются, то все нормально.

Не могли бы Вы подробнее объяснить, что значит "не используются full text key".

[uniqueman]

Вы сказали, что там две колонки зарегестрированы для индексирования. Вы в обеих колонках текст ищете?

да конечно, вроде параметр звездочка в предикате CONTAINS как раз обозначает что искать надо в обоих полях в моем случае.

Вообще, этот изврат с find и тестовым редактором я не понимаю для чего нужен. LIKE '%full%' должно работать не хуже.

когда я показываю текст в клиентском приложении, то мне нужно ключевые слова, по которым я осуществлял поиск выделять другим цветом. Следовательно мне надо найти их в контроле. Текст показывается в CRichEditCtrl. В этом контроле есть функция FindText, которая как раз ищет текст. Так вот в некоторые момент выделения цветом не происходит. Я сначала думал, что FindText глючит, поэтому ради эексперимента скопировал текст из контрола в текстовый редакторе и попытался найти там. Тоже пусто.

[8K]

Если некоторые - то не надо. Индекс, правда, разбухает.

у меня данные хранятся в таблице только за последние пять дней. Следовательно кажду ночь удаляются записи которые старше пяти дней.

Удаляются примерно 4000 записей каждую ночь. Это "некоторые" или нет?

Зависит от размера таблицы. Если в ней всего 20M записей - то "некоторые", а если всего 20K - наверное, проще делать full crawl после удаления.

[uniqueman]

Если некоторые - то не надо. Индекс, правда, разбухает.

у меня данные хранятся в таблице только за последние пять дней. Следовательно кажду ночь удаляются записи которые старше пяти дней.

Удаляются примерно 4000 записей каждую ночь. Это "некоторые" или нет?

Зависит от размера таблицы. Если в ней всего 20M записей - то "некоторые", а если всего 20K - наверное, проще делать full crawl после удаления.

размер всей базы - 300 мегабайт. Учитывая что это единственная таблица созданная мной, то наверное она и занимает основную часть всей базы. Значит "некоторые"

[8K]

Не могли бы Вы подробнее объяснить, что значит "не используются full text key".

переиспользуются.

Когда вы создаете full-text index для таблицы, вы назначаете один из ее UNIQUE single column индексов full-text key. Грубо говоря, значения full-text key хранятся в full-text индексе вместе с содержимым full-text columns.

Когда вы в своем запросе используете CONTAINS, он неявно превращается в вызов CONTAINSTABLE, который, в свою очередь, является прямым вызовом MS Search, результат - значения full-text key, удовлетворяющих критерию поиска. После этого результат JOIN'а с исходной таблицей ограничивает набор записей в исходном запросе.

Если вы обновили запись в таблице (удалили все вхождения слова foo), но она еще не ушла для индексирования MS Search'ем, вы можете получить обновленную запись как результат запроса CONTAINS(*, 'foo'). Это неверный результат.

Другая ситуация - если запись была удалена, а затем вновь создана, причем значение full-text key для новой записи - то же самое, что и удаленной. По-моему, у нас были баги насчет того, в каком порядке MS Search получает и обрабатывает эти два события. Если сперва DELETE, а потом INSERT - все нормально. Если наоборот - вы можете никогда не увидеть свою вновь вставленную запись, даже если она на самом деле содержит foo. Впрочем, если я не путаю и эти баги были действительно в SQL Server 2000, то они уже исправлены в одном из сервис-паков.

[8K]

Вы сказали, что там две колонки зарегестрированы для индексирования. Вы в обеих колонках текст ищете?

да конечно, вроде параметр звездочка в предикате CONTAINS как раз обозначает что искать надо в обоих полях в моем случае.

Я имел в виду, когда вы результат проверяете при помощи текстового редактора.

Еще хотел добавить, что есть принципиальная проблема, что корректность результатов не обеспечивается даже в пределах одной записи. Например, если в вашей таблице два BLOB'а (например, TEXT), то пока MS Search индексирует первую колонку текущей записи, SQL Server может обновить всю запись. Первая колонка использует старые значения, а вторая - новые.

Впрочем, вряд ли это ваш случай, т.к. вы говорите, что половина результатов неправильная. Тут что-то другое.