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

Да параметры можно прямо в строке вводить, где вызываемая программа указана. Командная строка она и в Африке командная строка (хотя зачем Занзибурундии командная строка? ).

А вот когда вызывать - это вопрос. Можно, конечно, чем больше вариантов, тем лучше. Но вот надо ли?

Ну почему же не угадал? Массив это и есть список.

Так это как раз то, что я описывал как приемлемый вариант организации БД. Это стандартный подход при отношении "многие-ко-многим": две таблицы (два массива в файле) и еще одна, которая "соединяет" две другие (это у Вас хранится в массиве файлов как номер каталога).

Да это нам не привыкать! . Кажется за последнии 3 - 4 релиза структура файлов менялась 2 раза. И ни чего живем. Вы же предупреждаете, когда меняете структуру. .

А дерево, мне кажется, будет еще комапактней, и в файле и в памяти. И к тому же есть уже готовые алгоритмы поиска по дереву. Туда же можно и файлы добавить - будет единая структура. Вот только с одинаковыми файлами нужно будет подумать. Хотя, наверное, таких мало по отношению к общему количеству фалов, и может быть, не имеет смысла с ними огород городить.

Ключевое слово "а то и ещё с чем"
Если есть вероятность выбора - то точно появятся недовольные. Мол почему мускул, а не "ЫЫЫЫ".

Чем команды мускула отличаются от обычных SQL-команд?
К тому же, для доступа к мускулу существует куча библиотек. Что именно использовать?

Когда программа и ФТП сканит, и кофе варит, и тапочки приносит - она получается, как правило, большой, неповоротливой и трудной в освоении.

А по поводу "кучу скриптов" - всё равно придеться писать скрипты для "выгребания данных по web-запросу".
Стоп! Возможно могу ошибиться, но данные в мускул можно штатно добавлять из файла.
Так что и скрипт писать не нужно, в самом шаблоне описываем команды добавления и всё.

MS Access не рекомендую: слишком ненадежная. А при увеличении размера БД до 500 - 700 Мб, летит только так. Несмотря на все, что пишет по этому поводу Microsoft.
Для других БД нужен либо дополнительный сервер, хоть и "мобильный", который надо ставить вместе с FI. А, вообще, смех: FI - 1.5 мега в дистрибутиве и сервер БД мегов на 20-40 к ней.

Есть еще FoxPro, но это надо встраивать поддержку в FI, если я не ошибаюсь. Да и не слишком производительные они, мне кажется. Хотя, я сталкивался не с последними версиями.

Можно использовать ADO, что входит в MDAC. Там есть поддержка большого количества форматов. Только вот не помню, можно ли создавать базу нужного формата с нуля из программы. Кажется какие-то можно. А было бы удобно, если можно было бы выбирать формат БД для хранения данных.

Ну почему же не угадал? Массив это и есть список.

Разве? Имхо "список" - это нечто со связью "к следующему" или "к предыдущему". (ну там одно- и двухсвязанные списки )

Да это нам не привыкать! . Кажется за последнии 3 - 4 релиза структура файлов менялась 2 раза. И ни чего живем. Вы же предупреждаете, когда меняете структуру. .

Нет, я менял структуру файла настроек, списков закачки и т.п. А вот строение базы файлов - ещё не менялось

Вряд ли, для дерева (связанного списка) нужно хранить ещё указатель на предка или на дочерние записи. А это лишнаяя память.
Но самое главное - деревья хороши для последовательного доступа. А мне часто нужно получать доступ к случайным каталогам.

Да хоть один такой файл будет - это уже возможное место сбоя.

Я имел ввиду, по отношению к дереву, массивы ближе к спискам.

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

Не понимаю зачем? При сравнении состояния сервера до и после опроса?

Почему??? Да хоть пять таких файлов. Если мы храним их в дереве, как листья, то какая разница есть у нас в разных узлах одинаковые файлы или нет. Или я чего-то не понимаю?

Ну 500-700 метров - такого нет, а так: работает моя БД, где хранилищем используется именно MS Access. Почти круглосуточно работает. Я туда только раз в месяц подхожу - старые бекапы почистить

Firebird-1.5.2.4731_embed_win32.zip - полтора метра, а в минимальном режиме - просто один файлик.

А разве там не должны быть уже готовые источники данных? Для ODBC нужно чтобы уже был источник, например "Access ODBC", и только тогда можно создать свой источник.

Если можно передать в БД SQL-команду "CREATE TABLE" (вробе бы), то можно создать БД.

Угу, выбрать тип используемой БД, выбрать формат данных в БД... Что ещё выбрать?
Тогда в дистр FI придётся включать и всё-всё-всё БД

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

"Дублировать" - в смысле в каждом узле записывать только имя текущего каталога? Хранить не "/dir1/dir2/dir3/", а только "dir3"?
Да, это более экономно, но получаем тормоза, когда требуется получить полный путь - придется "бежать" от текущего каталога до корня, конструируя путь.

Не понимаю зачем? При сравнении состояния сервера до и после опроса?

Опрашиваем некий каталог - нашли в нём 33 подкаталога, запоминаем на стеке их номера (указатели). Теперь прерываем опрос, перезапускам FI и хотим продолжить опрос. Считываем из файла массив индексов неопрошенных каталогов и ищем этот каталог.

Почему??? Да хоть пять таких файлов. Если мы храним их в дереве, как листья, то какая разница есть у нас в разных узлах одинаковые файлы или нет. Или я чего-то не понимаю?

Я просто продолжил мысль:

Неважно - много одинаковых файлов или мало - городить огород придётся!
Хотя никаких проблем тут нет, что в массиве, что в дереве - ну и что, пусть имена одинаковые

Еще раз извиняюсь, видимо я и так слишком много написал не поделу (аш некто прочесть не может)

А суть была такая, сделать ВАРИАЦИЮ проги (не дописать функций в эту версию а сделать отдельную) у которой будет целикам пхп интерфейс, а сам движок будет только запускается и получить все из бд, отсюда если на компе стоит апач, пхп и там можно запускать файлы (*.exe) то и мускул там тоже весьма вероятен (или кто-то так не думает) У мускула реальной альтернативы нет (михо, но тоже думаю не кто спорить не будет)

Если я не ошибась то нечем не отличаются (принципиально)

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

Нет, не обязательно. Хотя зависит от вида БД. Например, с SQL-сервером можно соединяться напрямую, без источника данных ОДБС и с базой Access кажется можно. Это для самого ОДБС нужен источник.

Нет. CREATE TABLE - это создать таблицу в БД. А вот создать саму БД это уже не SQL, а DDL (язык определения данных). И он, видмо, зависит либо от сервера БД, который и создает саму БД, либо от возможностей драйвера (точнее, провайдера) БД, который тоже может создвать файл БД, например, файл бд Access. Я это имел ввиду.

Не надо включать ни чего. FI только знает структуру своей БД (какие таблицы, их названия, названия полей, их тип и размер, связи между таблицами и т. д.). Причем, эта структура единая для все типов БД. Она общается с самой БД через ADO, а в ADO методы работы с БД одинаковы для всех поддерживаемых типов. Различается только строка подключения. Вот ее-то и определяем при выборе типа БД. Кстати окно выбора БД, там кажется уже встроено. И даже поставлять с FI ничего не надо. Кому нужно, тот качает с сайта микрософт файлик mdac_type.exe. В нем все и есть.

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

Видишь сколько уже "если" - это не дело.

Видел несколько войн на тему лучшей БД. В итоге (как обычно) вс остались при своём мнении

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

КАк-то я игрался с мускулом... Я смог без особых проблем добавить данные в таблицы из файла. Простейший батник, вызывающий какой-то .exe мускула и передающий аргументом путь к файлу. А в файле шли обычные SQL-команды "INSERT INTO...."

Итак, что получится:
0) Заранее создаем таблицу в мускуле (вот тут то в любом случае работаем ручками! В дистрибьютив FI я могу вложить лишь файл с описанием БД).
1) кто-то запускает FI, она сканит сервера и создает отчет по определёному шаблону.
2) после создания шаблона FI вызывает мускульный .exe с параметром "путь к файлу шаблона", в результате его в БД попадают все изменения.

Всё, и не требуется никаких скриптов. Плюс - не нужно очень уж сильно переделывать FI.

Ну мы же знаем, когда нам понадобится полный путь (или нет?), поэтому можем сразу конструировать его при пробеге сверху вниз. Хотя это, конечно, дольше, чем использовать готовый. Это известная проблема: экономим память, получаем больше работы кода.

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

Понял. Это я мысль потерял .

Нет, не обязательно. Хотя зависит от вида БД. Например, с SQL-сервером можно соединяться напрямую, без источника данных ОДБС и с базой Access кажется можно. Это для самого ОДБС нужен источник.

Для подключения "напрямю" нужна какая-то "прослойка" межд приложением и БД.
Тот же ODBC: выбирая источник данных, я могу работать с любой БД, ничего не меняя в программе.

Нет. CREATE TABLE - это создать таблицу в БД. А вот создать саму БД это уже не SQL, а DDL (язык определения данных).

БД создается один раз. Тут есть 2 варианта:
1) описать структуру БД, пусть админ её сам создаст.
2) положить в дистр файл с заготовкой БД... Нет, это не катит - БД бывают разные.
А описывать структуру на DDL - БД и в самом деле бывают разные...

Не совсем, для каждой БД должны быть установлены "ADO-драйвера".
Хм, а обязательно ADO? Не проще ли ODBC? А то лениво документацию по ADO читать

Хм, в этом случае получается некое дублирование - FI по прежнему хранит всё в .dat-файлах, но все изменения ещё и в БД заливает.

Ну мы же знаем, когда нам понадобится полный путь (или нет?), поэтому можем сразу конструировать его при пробеге сверху вниз. Хотя это, конечно, дольше,

А полный путь нужен весьма часто. Опрос сервера, создание отчета, создание списка закачек (добавление на закачку), поиск файлов, просмотр изменений,....

Да, с деревом здесь придется что-то придумывать.

А что тут придумывать - только перебор всего дерева в поисках каталога.

Дык именно так и сделано. "Номер каталога" - это его хэш от полного пути.
Каталоги хранятся в STL::map, а там поиск выполняется весьма быстро.

ОДБС - это самая нижняя прослойка. Можно работать непосредственно с ней, но это несколько низкоуровневое программирование, а оно трудоемко. Поэтому есть много всего: OLE DB (которое лишь тонкая надстройка над ОДБС) и ADO, например. На них проще и методы там универсальные для всех типов БД (я работал только с ADO, поэтому говорить буду только про него). OLE DB быстрее, чем ADO, но ADO, кажется, универсальнее.

А на DDL описывать не надо. В этом как раз преимущество ADO. Там, кажется, вызывается метод, типа, CreateDB и база создана в том формате, который используется в данный момент. То есть, для программиста не важен формат БД, так как он работает с функциями высокого уровня, а уже сам ADO транслирует их в инструкции DDL или SQL.

Нет. Опять не угадал . ADO ставится в комплекте с MDAC (компоненты доступа к данным Микрософт). И все поддерживаемые типы БД уже там есть. Файл дистрибутива один, бесплатный, качается с сервера мелкомягких. К нему есть еще SDK, если очень нужно.
Можно и на ODBC писать, только это гораздо сложнее и дольше, на мой взгляд.

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