В общих чертах задача следующая:
Необходимо реализовать клиенские части таким образом, чтобы они работали в отсутствии связи с основной БД. То есть необходимо использовать клиенские (локальные) БД и Основную серверную БД с программным механизмом синхронизации.
Основную серверную БД по любому придется далать на Oracle, а вот на что использовать в качестве локальных БД я никак определиться не ммогу.
.mdb - глупо и тормазно;
Firebird - много негатива последнее время слышу;
mySQL - на первый взгляд все устраивает.

У кого какие мнения будут?

pkarklinПо меньшей мере странно выбирать разные типы СУБД для "клиентской" и "серверной" части.

Ну использовать локальный Oracle на клиентских частях больно уж как то жестока

miksoftканалы связи, объем данных, интенсивность изменений на сервере и на клиенте, доступность клиентов для техподдержки, аппаратные ресурсы клиентских компьютеров?

Каналы связи - от 2-х мегабит до 256К

объем данных - всреднем за 2 года работы локальные БД на mdb разрослись до 40 мегабайт (но прогнозируется дальнейший рост количества записей в сутки).

интенсивность изменений на сервере и на клиенте - На клиенте в среднем 400 новых записей в день, клиентов ориентировочно 40 (от 1-го до 4-х на одном канале) итого на серваке в день получается 16000 записей. Интенсивность - реалтайм.

доступность клиентов для техподдержки - доступно вплоть до удаленного управления.

аппаратные ресурсы клиентских компьютеров - (точно не скажу) но ориентировочно можно взять за минимум среднестатистический рабочий комп на котором бегает Win 2000 - Cel 1200, 256 мозгов и винт 40.

hvlad Чернышов Вадим КонстантиновичFirebird - много негатива последнее время слышу;Отличный критерий для выбора, так держать !

PS не-не-не, не надо FB выбирать, умоляю автора...

А с чем связано то такое вот твое негодование от FB?

miksoftИмхо, FB - был бы неплохой выбор.
Для Oracle XE машинки слабоваты, но при наличии аппаратных возможностей я бы выбрал именно его.

Кстати, объем базы на клиентах какой предполагается?
нужно ли клиентам видеть то, что наработали другие клиенты?

Прогнозоровать объем пока не могу (уже говорил, что за два года использования в качестве бд Microsoft Office Access база распухла до 40метров)

Клиенты будут делиться на три вида:
1) Клиенты должны видеть все справочники (которые изменять они не будут иметь прав), и только свои записи (назовем их операциями).
2) Клиенты которые будут отвественными за ведение справочников
3) Клиенты, делающие общие отчеты, то есть должны видеть обсолютно все данные

Соответственно клиенты 2 и 3 могут работать только в случае доступности сервака, а клиенты 1 могут работать в любом состоянии.

Да еще докучи, может кото видел в инете сравнительную табличку СУБД с плюсами и минусами?

miksoftТ.е. единственное, во что упирается выбор - аппратные возможности клиентских компьютеров и ваш вкус и умения.

На самом деле для поставленной задачи имеющиеся на вооружении аппратные возможности клиентских компьютеров с использованием скажем FB или mySQL вполне пригодны, я писал программки под FB боловства ради, с использованием mySQL уже более серьезные вещи но то была одна серверная БД с нормальным клиентсерверным приложением (без использования локальной БД), которые уже эксплуатируются. Но вот сейчас намечается проект очень серьезный, поэтому обратился за советом, чтобы заранее знать про возможные подводные грабли :)

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

miksoftклинетам 2 и 3 локальная база не нужна?


В чистом виде нет не нужна, но могут существовать клиенты гибриды, например гибрид 1 и 2.
То ксть должен видеть все свои операции, но при построении какого либо общего отчета лезть уже непосредственно на сервак за общими данными (ну это легко реализовать - есть конект хорошо, нате вам данные, нету конекта - досвидос! ;) )

miksoftИнсталляция ни у Oracle XE, ни у FB, ни у MySQL не вызывает особых проблем, особенно если любой из последних двух использовать в Embedded варианте.

Я бы больше заострил внимание на механизмах взаимодействия с центральной БД.

Взаимодействие с Центральной БД будет реализовываться исключительно программно, своими сылами без всяких сторонних механизмов синхронизации.

hvlad Чернышов Вадим Константинович hvlad Чернышов Вадим КонстантиновичFirebird - много негатива последнее время слышу;Отличный критерий для выбора, так держать !

PS не-не-не, не надо FB выбирать, умоляю автора...

А с чем связано то такое вот твое негодование от FB?Оно не от FB.
Развивать флейм не намерен, как и участвовать в нём

Не намерен не развивай, только для избежания флейма нужно ответы четкие давать, а вот что тебя что hvlad я так и не понял.

Вот тебе четкий вопрос - стоит ли использовать Firebird или нет, и обоснуй почему?

(Ты наверно мало с топ менеджерами лбщаешься, их как правило простые ответы вид "да", "нет" и уж темболее "незнаю" как правило не устраивают ;) )