DremlinЗдравствуйте..Здравствуйте

DremlinКлиент должен работать (только чтение данных) с наборами таблиц локально. Таблицы будут выгружены с SQL Server'а или в виде Flat-файлов, или в виде файлов dbf, и отправлены клиентам.DBF = > Visual FoxPro

DremlinСложность заключается в том, что объемы данных могут быть большими (порядка 2-5 млн записей в таблице) и, как я думаю, работа настольной СУБД, например, как Paradox, будет очень медленнной.Быстрее, чем Fox работает с локальными dbf-таблицами, ничего не найти. 5 млн. записей - не проблема. Единственное ограничение - размер одной таблицы не может превышать 2Gb. Это связано с применяемой технологией блокировок.

DremlinПри работе же с текстовыми файлами встает вопрос производительности и сложность обработки данных (т.е. в клиентском приложении будет множество DML операций, и как работать с простыми текстовыми файлами... отается проблемой).В твоем распоряжении будет богатый DML, так что здесь даже обсуждать нечего

DremlinНаши специалисты говорят, что настольная СУБД не подойдет для больших объемов данныхА чем ваши специалисты аргументируют? Этико-религиозными соображениями?

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

Настольные БД
а) Требуют намного меньше ресурсов
б) Данные занимают меньше места (в разы)
б) Работают гораздо быстрее (локально - в десятки раз)

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

В вашем случае:
а) Шифровать данные и разделять права доступа не требуется
б) Данные не редактируются, поэтому сбои исключены
в) Одновременная работа десятков пользователей в одной базе не нужна

И в чем преимущество "не настольных" СУБД? Наживать себе гемморой только потому, что вера не позволяет использовать что-то кроме Oracle?

Я вам советую провести пару простых тестов. Установите Фокс. Создайте пустую таблицу, и добавьте в нее свои 5млн. записей из текстового файла. Выполните несколько запросов. Потом проиндексируйте ключевые поля и снова выполните те же запросы. Сравните время выполнения этих операций с аналогичными действиями на SQL Sever. Думаю, надобность писать в этот форум отпадет.

Да, еще. Если речь идет о печати квитанций - в Фоксе есть встроенный генератор отчетов. Он достаточно прост, зато быстр. Для печати квитанций - то, что надо. Говорю это, исходя из собственного опыта - приходилось распечатывать отчеты по 6тыс. страниц.

Конкретные данные:

Таблица dbf - (F1 c(100), F2 N(10.0), F3 D, F4 L) 5млн.записей занимает 572Mb. Экспорт этого объема в текстовый файл - 37 сек, добавление из текстового файла - 42 сек. Поиск случайного значения по полю F2 (N10.0) - не более 2 сек без использования индексов.

Комп - PIV 2Ггц, 256Mb
Операционка - Win2000, NTFS, антивирус отключен.

2 Локшин Марк
Вместо "не верю" лучше проделать то же самое и сказать "А у меня получилось в 10 раз больше/меньше".

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