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

ЧернышовЧВК> Вот тебе четкий вопрос - стоит ли использовать 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 не на многоменьше занимают место.