Привет!

Пишу на VFP9 прогу как файл-серверное приложеньце. Все базы являются "свободными" (.dbf). Клиентам просмотры организованы через гриды посредством выборки нужных полей из нужных баз в курсоры с помощью SELECT SQL. Со временем оказалось, что некоторые базы (в корых сохраняются документы типа .doc) растут в размере очень быстро и, поскольку SELECT SQL открывает все указанные в запросе базы локально, все это загружает сеть и замедляет выполнение выборок + открываются нерадужные перспективы на будуНИщее :) .
Что посоветуете в данной ситуювине? К примеру переход на клиент-серверное приложение я не рассматриваю, т.к. знаний в этой сфере 0, хотя предполагаю, что в таком случае выгода такая - клиенту отправляется только результат выборки, соотв. он не нагружается всеми базами, что в ней участвуют. Это, конечно, здорово, если так, но пока что не вариант отчасти потому, что пишу прогу во-первых бесплатно, и во-вторых, заказчик просит не использовать сторонние небесплатные проги. Поэтому вместо M$-Word я планирую юзать OO-Writer, а про SQL-Server как бы вообще не думаю, хотя знаю про существование mysql.
Сам пока что вижу выход только в разбиении быстрорастущих баз на части, например отрузать базу с доками в отдельную.

Спасибо.

В принципе меня уже посещала идея выкладки док в отдельную папку. Поскольку есть идентификатор (IAi) то его и можно было бы как имя файла задать конвертив в строку. Но тогда меня смутило ограничение файловой системы на кол-во файлов в одной подпапке... правда не знаю чему оно равно, но оно есть. Само собой 1ну доку перетащить по сети или все сразу ради одной - вроде как выбор ясен...
Кто скажет какое существует ограничение на количество файлов в подпапке для систем FAT32 и NTFS? Под подпапкой имею в виду, что папка не в корне. Дело в специфике работы заказчика, там за год может проходить от 50 до 150 тыс. док.

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

ну есть и другие тынцы :)
http://en.wikipedia.org/wiki/NTFS
http://ru.wikipedia.org/wiki/FAT

выходит что можно и в папку, но при условии что сервак будет на NTFS...

эх, забыл отметить, что ограничения и там и там таки есть.

спасибо!
значит надобно обязательно поиндексировать ВСЕ поля, что участвуют в выборках в WHERE и JOIN ON?

PaulWistбольшое заблуждение, что на клиента будет передаваться больше данных, данных будет передаваться столько сколько необходимо для выполнения запроса, конечно если запрос полностью оптимизирован и Фрксу не придется в тупую сканировать все записи таблицы. ну я может и заблуждаюсь, но выполнив выборку, абсолютно все базы, что в ней участвовали, на машине клиента оказываются открытыми. А это значит вместе с индексами, что в свою очередь говорит о том, что эти базы были с потрохами переданы с сервера клиенту. это же не клиент-серверное, а файл-серверное приложение.
Т.е. насколько я понимаю, практически все происходит следующим образом - все участвующие в запросе БД сперва закачиваются на машину полностью, затем из них уже локально происходит выборка. А поскольку индексы оптимизят выборку, то и они приедут в полном составе :) Другое дело что сама выборка проидет быстрее...