В общих чертах задача следующая:
Необходимо реализовать клиенские части таким образом, чтобы они работали в отсутствии связи с основной БД. То есть необходимо использовать клиенские (локальные) БД и Основную серверную БД с программным механизмом синхронизации.
Основную серверную БД по любому придется далать на 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 или нет, и обоснуй почему?

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

Мимопроходящий
Привет, Чернышов!
Ты пишешь:

ЧернышовЧВК> Вот тебе четкий вопрос - стоит ли использовать Firebird или нет тебе - ни в коем случае!
ЧернышовЧВК> и обоснуй почему?категорически противопоказано при нарушениях ЦНС.

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.4

Опять жеж флейм, понятие стобильности нервной системы тоже бывают разними.
А от вас грамотного ответа видемо тоже не получить. Это разве ответ: Нет потому что нервы себе угробишь? ;)

To: hvlad
Ну простите, не угледел что ты тут один такой хВлад ;)
Я это заметил уже позже но отредактировать написанное тут уже невозможно (или я непонял как.)

Вот теперь я понял, что тебе по нраву использовать Firebird, и ты скрытым текстом мне его советовал ;)

Увольнять человека за его словоблудие глупо! :)

Удачи hvlad

S.G.Если Вы менеджер, наверное стОит спросить в первую очередь у своих разработчиков?

Я как раз и есть разработчик, но четкий ответ могут дать скорее всего технологи, которых у нас к сожалению нет.

Стоит взвесить все методы реализации и доступа к данным.

Основным постулатом будет служить то что, прямого доступа через какие либо компоненты Delphi к данным у пользователей может быть лишь просмотр, остальное (добавление, редактирование, удаление) только через SQL запросы, это, на мой взгляд, гарантирует более надежную проверку данных на соответствие бизнес-логики приложения. Используемые компоненты будем использовать только для соединения с БД плюс получение и выполнение SQL запросов и команд. Компоненты вудзрш должны быть на 100% фриварными.

1. Расмотрим вариант с Firebird

Установка самого Firebird достаточно не трудоемкий процес, который также можно реализовать при установки приложения (осталось только инсталятор нормальный найти, или свой написать).
А дальше вариации:
1) Клиентская часть на Delphi с использованием родных компонентов delphi – Interbase, что гарантирует отсутствия необходимости использования всяких дополнительных драйверов и dll.
2) Клиентская часть на Delphi c использованием фриварных компонентов ZEOSDBO, но для функционирования потребуются дополнительные dll, которые нужно помещать в каталог system32 или system.
3) Клиентская часть на Delphi с использованием родных компонентов ADO, доступ к данным осущиствлять через драйвер ODBC, для чего понадобиться настройка системного DSN.

Теперь плюсы и минусы. 1 и 2 – ой вариант на мой взгляд наиболее трудоемки и требуют дополнительной трудоемкости при установке, Плюс в ADO и ZEOSDBO не развито понятие транзакций, тоесть там транзакция в рамках одного подключения. То есть если фоном паралельно с работай клиента будет работать механизм синхронизации с основной БД, придется использовать два подключения к локальной БД.

2. Рассмотрим вариант с mySQL
Устаноку также можно автоматизировать с использованием инсталятора, но по сравнению с Firebird на мой взгляд проблем побольше. (если я не прав поправте меня)
Соответственно вариации:
1) Клиентская часть на Delphi c использованием фриварных компонентов ZEOSDBO, но для функционирования потребуются дополнительные dll, которые нужно помещать в каталог system32 или system.
2) Клиентская часть на Delphi с использованием родных компонентов ADO, доступ к данным осущиствлять через драйвер ODBC, для чего понадобиться настройка системного DSN.

Плюсы и минусы:
2-ой вариант я уже как то реализовывал и сталкивался с проблемой, что в ODBC драйверах слетает кодовая страница и еще чтото в итоге в клиентсвой части начинается бардак 1-ый вариант в этом отношении надежнее, но при установки понадобятся дополнительные dll.


Далее рассмотрим некие особенности обеих СУБД

Транзакции.
Транзакциях в mySQL, на сколько мне известно mySQL это понимает начиная с 4-ой версии и реализовано это на уровне запросов, то есть можно сделать «командным» запросом начало транзакции и ее завершение (подтверждение, отклонение).
Для Firebird для механизма транзакций можно использовать встроенные в Delphi компоненты, на уровне SQL запросов – незнаю.

Тригеры и хранимые процедуры:
Хранимые процедуры в mySQL появились начиная с 5-ой версии, а тригеры с версии 5.0.2, и на сколько это все ровно работает мне не известно.
В Firebird и тригеры и хранимые процедуры появились достатчно давно, и нареканий я не слышал. (поправте если у кого есть опыт).

Судя по всему выше написанному я пока склоняюсь к Firebird.

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


У кого какие мнения будут, рвд буду выслушать!

Вот еще что забыл.
Установленный mySQL 5.0 занимает 101 Мегабайт, а Firebird 15 мегабайт.

miksoftВы рассмотрели только методы доступа к данным, которые, собственно, с самой СУБД не очень-то и связаны. Причем из всех возможных рассмотрели не самые лучшие. Забыли, например, AnyDAC и FIBPlus.
При выборе СУБД методы доступа также имеют весомый аргумент.
Насколько я знаяю AnyDAC и FIBPlus платные.
miksoft
Транзакции в MySQL зависят не от версии, а от движка. В частности, в InnoDB транзакции есть, в MyISAM - нет.

Это я тоже знаю, я указывал сам факт существования транзакций.
miksoft
При нынешних объемах носителей - это копейки. Тем более, что вы упорно не обращате внимания на слово embedded, которое в этом топике упоминали уже несколько раз.
На сколько я смотрел версии embedded не на многоменьше занимают место.