По отзывам знакомых ребят, совершивших такой переход, "плохого" в общем-то нет; просто нет многого привычного "хорошего".
Re[2]: Oracle | FireBird help
От:
Аноним
Дата:
16.11.05 08:03
Оценка:
Здравствуйте, Softwarer, Вы писали:
просто нет многого привычного "хорошего".
— Можно 1 маленький пример: это можно и легко на Oracle и нельзя
(или с большими трудностями) на FireBird
— Есть ли ограничения на обьем базы, после которого начнуться коллизии
Здравствуйте, <Аноним>, Вы писали:
А>C oracle знаком давно. А>С Firebird(Interbase) не знаком.
А>Что есть "Плохого" у Firebird?
Сравнение несколько некорректное по определению. У каждого из серверов есть плюсы и минусы. Про Firebird можно почитать здесь — много, подробно и по-русски. Из плохого, пожалуй, только отсутствие встроенных функций на версиях 1.х, но и это не критично, ибо всегда есть возможность подсунуть "внешнюю" функцию из UDF.
Здравствуйте, <Аноним>, Вы писали:
А>- Можно 1 маленький пример: это можно и легко на Oracle и нельзя А>(или с большими трудностями) на FireBird
Например, у Oracle есть табличные функции. С их помощью довольно легко вернуть столько и такие данные, которые нужны. На Firebird это не реализуемо, ибо нет у него табличных функций. Как собственно и вообще объектов. Зато есть возможность реализовать селективные SP, чего нет в Oracle.
В Oracle, например, при написании хранимок и пакетов (а пакетов в Firebird нет) ты не ограничен только PL/SQL и можешь написать его на JAVA. У Firebird этого тоже нет — только SQL и ничего больше. Но, по большому счету, этого вполне достаточно. А недостающий функционал легко реализуется с помощью UDF.
А>- Есть ли ограничения на обьем базы, после которого начнуться коллизии
Что-то в районе 32 гигов на файл. Точно не помню, но можно поискать здесь.
Здравствуйте, Horror_Infinity, Вы писали:
А>>- Есть ли ограничения на обьем базы, после которого начнуться коллизии
H_I>Что-то в районе 32 гигов на файл. Точно не помню, но можно поискать здесь.
Что цифра какая-та несуразная
FireBird, начиная с релиза FB1, использует 64-битную адресацию для чтения-записи файлов.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Что цифра какая-та несуразная
Сорри. Уже давно не работал с FB по хорошему, то есть плотно. Видимо, эта инфа у меня отложилась еще со времен IB. Посыпаю голову пеплом и иду читать доку.
Здравствуйте, <Аноним>, Вы писали:
А>Каковы все же — , или это большой секрет
Нет, не секрет. Почему ты так упорно не желаешь сходить сюда и почитать?
А>Для биллинговых систем FireBird пригоден ?
Да.
А>Есть ли у FireBird средста отслеживания событий, происходящих в БД,
Да. А>автономные транзакции.
Да.
Здравствуйте, Аноним, Вы писали:
А>Хорошо пусть это +,
А>Каковы все же — , или это большой секрет
Часто народ ругает оптимизатор, хотя мне лично откровенной и неисправимой кривизны видеть не приходилось, поэтому к народу не присоединюсь.
Выполнение некоторых запросов не соответствуют стандарту (например уже упоминавшиеся
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Насколько я понимаю этот термин (возможность стартовать/комитить/откатывать транзакции в триггерах, хранимых процедурах), то такого в FB нет.
Хм. Безотносительно к автономным транзакциям — следует ли понимать так, что в ХП в FB нельзя выполнять команды start transaction / commit?
КД>Зато есть точки сохранения — savepoint-ы, которые можно создавать как на клиенте так и в триггерах, хранимых процедурах.
Если в понятие savepoint в FB вкладывается тот же смысл, что и в Oracle — это не "зато"; оно само по себе хорошо, но не заменяет автономных транзакций.
Простой пример автономной транзакции — лог. То есть, я делаю примерно следующую хранимую процедуру:
create or replace procedure WriteLog ( Msg varchar2 ) is
pragma authonomous_transaction ;
begin
insert into Log ( log_id, message ) values ( log_seq.nextval, Msg ) ;
commit ;
end ;
После этого я пишу большую и сложную хранимку, в которой веду лог — например, в отладочных целях:
create or replace procedure SomeBusinessFunction ( Param1 integer, Param2 varchar2 ) is
begin
savepoint saveSomeBusinessFunction ;
WriteLog ( 'SomeBusinessFunction::Param1 = ' || Param1 || ' Param2 = ' || Param2 ) ;
.....
WriteLog ( 'SomeBusinessFunction - ok' ) ;
exception
when others then
WriteLog ( 'SomeBusinessFunction - ERROR! ' || sqlerrm ) ;
rollback to savepoint saveSomeBusinessFunction ;
end ;
В итоге, если выполнение этой хранимки завершается с ошибкой, ее действия откатываются, но я вижу лог происходившего во всех подробностях. На savepoint-ах, боюсь, такого не сделать.
Здравствуйте, Softwarer, Вы писали:
S>Безотносительно к автономным транзакциям — следует ли понимать так, что в ХП в FB нельзя выполнять команды start transaction / commit?
Да, управлять транзакцией внутри ХП — нельзя.
S>В итоге, если выполнение этой хранимки завершается с ошибкой, ее действия откатываются, но я вижу лог происходившего во всех подробностях. На savepoint-ах, боюсь, такого не сделать.
Да, это факт. Но ты не бойся, если нельзя — значит и не надо
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Привет, OLEGus1!
Вы пишешь 16 ноября 2005:
А>> Что есть "Плохого" у Firebird?
O> Мне не нравится хранение всего в одном файле. O> Это и философски и программно неправильно.
Глубоко. Очень.
O> Особенно, в этом контекте, радуют процедуры gbak и gfix.
Здравствуйте, Alex.Che, Вы писали:
AC>Глубоко. Очень.
А что мелко? Ну и какие премущества имеет хранение всей базы в одном файле? кроме того, что теряя один файл теряешь всю базу?
AC>Ещё глубжее.
Да, тоже мелочи, делать по многу часов бэкап, а потом еще столькоже разворачивать. А еще веселее становится, когда развернуться база не может без gfix'a, или даже с ним не может.
Можно поподробнее?
