А точнее - индексирующий сервис.
У меня задача в чем-то отдаленно напоминает такую же...
Интересно, как он знает, какие файлы надо про- или переиндексирвоать?

Есть набор фолдеров (или весь диск), которые надо проиндексировать.
Пускаем сервис, он работает, все гут.
Но по ходу работы появляются новые файлы, изменяются - ну предположим эти события можно ловить через FileSystemWatcher и доиндексировать..

А если остановить сервис и потом пустить его через какое-то время?
Откуда он знает, с чего начинать, откуда продолжать?
Хранит где-то свою базу с именами уже проиндексированных файлов?

mayton1База хранится на локальном диске. Это скрытая директория с файлами в корневом каталоге.

Текстовый индекс MS-Indexing Serv это не аналог индекса в БД и
его состояние не всегда актуально.

это да.
А вот алгоритм работы интересует.
Стартонул сервис, он идет по файлам, и видимо пишет информацию о них в свою базу.
Потом я его остановил, стартонул через два дня снова. Что дальше он делает?

Сканирует снова все файлы и сравнивает со своей базой на рпедмет надо ли индексировать.
А если скажем при активном сервисе добавится или изменится много файлов, он не потеряет информацию о том, что изменилось?

МихаилР,

спасибо за столь полезный ответ!

Думаю Windows Search имеет АПИ, с которым можно работать из приложений, или из T-SQL.
Т.е. так же как и Indexing Service имеет.

МихаилРWinnipuhДумаю Windows Search имеет АПИ, с которым можно работать из приложений, или из T-SQL.
Да, если вы хотите использовать WS для поиска, то посмотрите на статью Querying the Index Programmatically , а особенно (мне кажется, это наиболее простой вариант) на Using SQL and AQS Approaches to Query the Index .

Единственное, если вам придется писать собственные провайдеры хранилищь, это уже будет не шибко тривиальная задача, хотя и решаемая. А если индексировать придется только локальные файлы - все уже есть.

мне надо сркщивать поиск в базе и поиск в файлах, файлы как-то связаны с объектами в базе (мс скл)
сейчас я использую поисковые запросы из t-sql, но это не очень хорошо о производительности. Пытаюсь найти решение, возможно использовать внешний поиск, типа lucene

МихаилРWinnipuhмне надо сркщивать поиск в базе и поиск в файлах, файлы как-то связаны с объектами в базе (мс скл)
сейчас я использую поисковые запросы из t-sql, но это не очень хорошо о производительности.

Не до конца понял - поправьте, если что:
- у вас локальное приложение, которое сохраняет что-то в базе и в неких файлах (если не локально, то Windows Search не самое лучшее решение, хотябы потому, что поддерживает только 1 индекс - на машину. Тут лучше смотреть на специализированные поисковые сервера - тот же MS Search Server. Ну или делать свое).
- для поиска вы используете кросс-запросы из T-SQL (которые, как я помню, адресуются в Indexing Services). Т.е. одним запросом поиск и по базе, и по файлам.
В целом логичное решение. Только почему не устраивает скорость... Не думаю, что будет какое-то радикально более быстроее решение.

Или я чего-то недопонял?

все правильно, т.е. в базе для объекта записаны имена файлов и еще дополнительаня информация, ищу и в базе, и в соответствующих файлах и потом объединяю в виде суммарного результата для объекта.
да, файлы на сетевых дисках, именно к индекс серверу обращаюсь из транзакта.

Для больших баз не очень хоршая скорость, это связано со спецификой задачи.

Я экспериментирую в том смысле, что скажем в lucene я создаю параллельно индексы, и поиск в них делаю тоже запуская несколько параллельных запросов, потом объедняю их, люцен может так делать... и он же может индексировать файлы... Естественно, вопросы транзакционности пока не рассматриваются.
Не очень хорошая производительность на больших базах, где полнотекстовые каталоги занимают гиг 50..

МихаилР,

спасибо!
продолжу эксперименты