Поиск на сервере с сайта, Вопрос не только к автору. Ко всем.

Мне кажется, Вы ошибаетесь. Содержимое файла dat представляет собой (я полагаю) дерево (я не говорю сейчас даже о хранении удаленных файлов), сброшенное в файл. Когда программа манипулирует этим деревом, то она всё его загружает в память, а уже потом отображает в интерфейсе или выполняет поиск по нему, поэтому как оно физически хранится не очень важно. Таблица же организована ввиде списка. Если мы каждую ветку дерева:

преобразовываем в:

корневая_папка\Папка1\Файл1
корневая_папка\Папка1\Файл3
корневая_папка\Папка2\Файл2

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

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

Но опять повторюсь, это мое представление организации файлов *.dat. И в общем случае нужно оценивать затраты на заливку данных в БД и скорость получения ответа на запрос к этой БД и затраты на считывание данных из текстовых файлов, полученных шаблонным способом из FI или даже чтение на прямую из файлов *.dat. Не факт, что работа с БД будет производительнее.

Хотя сейчас посмотрел на файл *.dat в текстовом редакторе: чего-то он не очень похож на дерево. . Точнее совсем не похож. Больше похож на список.

Нокаут! Действительно, как-то мне это в голову не пришло сразу.
Только это должно быть действительно в самом конце сканирования (после создания всех всех отчетов и проч.
Может уважаемый автор добавит такую функцию? Наверняка её внедрение не потребует серъезного изменения ядра...

Я, кстати, и у себя ее добавить попробую... Уж больно здоровская идея!

Если есть желание отделаться "малой кровью" то можно добавить возможность запуска.... но, вот таблице всеже куда эффективнее, даже в новой версии NTFS (или WinFS) была идея хранить мелкие файлы в MTF (аля база данных) так что про производительность лутше неспорить, да и текст в пхп не так удобно обрабатывать как баблицу.

Опрос производится с помощью FI, а вот выдача результатов (и соответственно - хранение данных для Web-запроса) сделано точно не в FI.
Скорее всего именно описанный вариант: FI создает отчет по шаблону, этот отчет заливается в БД. Далее php.

После завершения сканирования или после создания отчета?
Реализовать такое не сложно.
Всегда вызываем одну и ту же внешнюю программу или каждому серверу по личной?
Какие параметры нужно передавать в вызываемую программу?
Хотя.... Можно же все "параметры" (имя сервера, дата опроса, .....) указывать в шаблоне.
Значит достаточно вызвать внешнюю программу и передать ей путь к файлу-отчета?

Согласен. Если только использовать embedded-БД.

Это когда FI столько кушает? Если только во время поиска файлов, но это делается только по команде юзера

Одновременно опрашивать 400 серверов?!!!!!!
Могу только посоветовать поиграть задержкой между опросами каталогов.

Что-то подсказывает мне, что так оно и будет . Но возможно все.

Ага! Ленивее меня - это ещё поискать нужно
Но вариант "запуск внешней программы" - это что-то интересное...

Индексацию, имхо, будет не сделать.

И снова не угадал
Там ...хм... 2 "таблицы" - массив каталогов и массив файлов.
А файлы просто ссылаются на "номер каталога".
Может не самый лучший вариант, хотя данные весьма компактные получились
Идея сделать дерево (по крайней мере для каталогов) - имеются. Заготовка уже есть, но придеться менять структуру .dat-файлов.

Именно это для начала иреализую.

Насколько я слышал, реализация WinFS с БД то ли загнулась, то ли отложена на дальнюю полочку.

А по поводу БД - _какую_ БД использовать?
К БД подавай ещё что-нить типа "ODBC-драйверов", а это лишние телодвижения для пользователей.
Это проблема с режимом "скачать с сервера готовую базу".

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

Да нет, всего по 25 потоков . А вот 400 потоков - это надо попробовать .

Пряматаки жаль!

Просто все подобные проекты расщитанные на веб работают с мускулом а то и еще с чем (как опция) а юзать это будут админы, так что про проблемы с дровиной можно забыть )) но команды мускула выучить пришлось бы!

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

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

Дык задержка между опросами каталога именно для этого и сделана - меньше кушаем процессора. (Но и дольше опрашиваем).

Да нет, всего по 25 потоков . А вот 400 потоков - это надо попробовать .

Если используешь ХРюшку, то она скорее всего от такой радости упадёт
Почему - не знаю, главное что винтукей у меня не падает.