Вы конечно, меня извините,

[metaclass]

но PostgreSQL с первого взгляда выглядит более правильной СУБД чем Firebird.

1) Логи, много понятных логов. Небо и земля, по сравнению с ничего не значащим бредом, которым firebird.log заполнен чуть более чем полностью. Т.е. там даже нет возможности включить что нибудь вроде "протоколирование доступа к базе", не говоря уже о запросах, итд.

2) Читабельный вывод консольных утилит. Posix-командная строка этих самых утилит. Вменяемые параметры их же.

3) Несколько вариантов аутентификации, управление аутентификацией c детализацией по адресам-маскам, именам базы, юзеров

4) доступ через ssl.

5) И наконец, ключевой аспект: документация. 2100 страниц нормальной понятной хорошо структурированной документации, доступной в виде PDF с официального сайта. В отличие от, блядь, документации по Interbase 6 на которую до сих пор ссылаются на сайте FB и потока сознания разработчиков в виде quick start quide и release notes.

Comments

[enternet.livejournal.com]

Не вижу ничего позорного, если имеете доказательства, прошу предоставить. Усвою и поблагодарю. А опыт у меня ровно обратный.

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

А вы паясничаете, по сути.

Что вы хотите мне доказать мелкими придирками? Что IB быстр, документирован, надежен и беспроблемен в эксплуатации? Вы до сих пор впариваете доверчивым людям эту чушь?

Да я специально этот тред завел только ради того, чтобы поделиться своим опытом с IB/Firebird. И я верю, что плохие решения должны умирать, а хорошие - жить. Надеюсь кто-нибудь прочитает это, и НЕ КУПИТ решение на базе IB. Вероятность низка, но тем не менее.

Ещё раз, не отвлекаясь, повторяем мантру все вместе: Interbase/Firebird - это некачественное, плоходокументированное, медленное, проблемное в эксплуатации семейство серверов.

[enternet.livejournal.com]

Нарушаете первую заповедь, грешник ) Идентификатор - есть ничто по форме своей и в ничто уйти должен.
Нельзя на него накладывать никакой допфункционал, покайтесь )

[denisioru.livejournal.com]

Много изменилось? Я недавно смотрел баглист актуальный. Помню открытые баги по поводу некорректной sum в подзапросе, ошибки бакапа, кстати дифференциальный бакап-то сделали уже или как? На дворе 2010й, пора бы уже.

[vp.livejournal.com]

Читаем внимательно.
Требование к генератору было такое, чтобы потом было возможно наиболее простым методом смержить базы с разных мест. По сути дела можно было бы использовать подобие ГУИДа.

[enternet.livejournal.com]

Ну так и использовали бы GUID'ы. Кто-то (может даже сам господин Кузьменко) помнится целую статью написал "как использовать PK GUID на IB чтоб индексы не распухали".

[vp.livejournal.com]

ГУИДы были забракованы, т.к. их глазами читать могут только инопланетяне.
Цель всех разработок - обеспечить беспроблемную отладку и сопровождение в будущем. И мне намного проще понять по десятичному числу, в котором младший разряд = "точка создания", чем пялиться в гуид или создавать еще одну сущность (хотя она есть) типа "где создана запись". Мы за хьюман читабельность по возможности всего :)

[metaclass.livejournal.com]

Опенсорсный только IB6, очень допотопный. FB основан на его коде.
Самодельные билды действительно не практикуются - мне хватает разборок с чужими ошибками, не хватало еще со своими разбираться :)

[metaclass.livejournal.com]

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

С медленностью вопрос неясный. На данный момент у меня три варианта медленной работы: 1) устаревшая статистика индексов. Лечится однократным ее обновлением. 2) Загадочное поведение на некоторых виндовых серверах (на линуксах не пробовал, не знаю) - тупо работает в 5 раз медленнее чем на аналогичных машинах. В чем причина - то ли SATA контроллеру стиль работы не нравится, то ли диск сдыхает, то ли в FB что-то не то - не знаю. 3) Мой личный плющ - где то остается не завершенная транзакция и начинает расти разрыв между oldest snapshot и текущей транзакцией, из-за чего перестает собираться мусор и начинает тупить. При моих сотнях транзакций в секунду это быстро складывает сервер.
Я не знаю, что в таких случаях делают другие версионники - не пробовал.

[metaclass.livejournal.com]

Там это сознательно нарушение заповеди. Чтобы не сойти с ума.

[metaclass.livejournal.com]

Довели страну, ага :)

[enternet.livejournal.com]

Слушай, у тебя тут прям медом намазано. Уже и господин Тарасов (Арбинада) появился.

[metaclass.livejournal.com]

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

[metaclass.livejournal.com]

А, там жыж надо как-то хитро их переворачивать, чтобы последовательность кошерная была для вставки в b-tree.
Но вроде сейчас уже это не поможет - микрософт какое-то дополнительное вуду-хэширование сделало для генератора гуидов.

[metaclass.livejournal.com]

Он здесь давно уже.
Я по его статьям проектирование баз данных когда-то давно осмысливал.

[enternet.livejournal.com]

Про SATA не знаю, а вот на вот на некоторых SCSI-контроллерах такая фигня была. Причем не на всех. У себя - всё нормально, а у заказчика прям было слышно по звуку как контроллер всё в пакеты раз в секунду отдавал.

[denisioru.livejournal.com]

Ну в некоторых случаях вариантов не остается. Вот представь как ты будешь full backupить базу в пару терабайт. Вопрос даже не в количестве байт, вопрос во времени бакапа и в случае необходимости - развертывания этого бакапа. В том же mssql можно совмещать разные мезанизмы, типа full + diff + log, или full + file backup + log. В итоге в случае отказа можно восстановить достаточно быстро. Да и места немного тратится, ибо редко встретишь БД, в которой каждодневно меняется больше 10% данных, остальное обычно лежит не меняясь.

[enternet.livejournal.com]

Да, но для любителей старых инкрементных GUIDов майкрософт оставил нужный функции.

[denisioru.livejournal.com]

Кстати, а в IB/FB можно посмотреть планы запросов оптимизатора? А то не припомню, давно уже не использую его.

[metaclass.livejournal.com]

Вообще API возвращает после prepare.
Если в консольной утилите isql - то что-то вроде SET PLAN ON или SET PLANONLY ON

[gsbelarus.livejournal.com]

"дифференциальный бакап-то сделали уже или как?"

см. утилита nbackup

[interbase.livejournal.com]

>Не вижу ничего позорного, если имеете доказательства, прошу предоставить.
Позорно то, что Вы не задумываясь транслируете чужие заблуждения. Если бы Вы задали вопрос, я бы ответил. Но Вы стали УТВЕРЖДАТЬ что план запросов вкомпилирован в процедуры.

Тем не менее, опровержение повторяемого Вами заблуждения найти очень даже можно:
1. берете любую базу IB/FB с процедурой, в которой есть запрос.
2. открываете базу в IBExpert.
3. select * from rdb$procedures
4. в записи с нужной Вам процедурой есть столбец rdb$procedure_blr. Тыкаете в его содержимое. Это блоб.
5. переключаетесь в закладку as BLR.

Я хотел было привести сюда пример примитивной процедуры, но форматированный blr занимает много места. приведу отдельно.

>Что вы хотите мне доказать мелкими придирками?
почему мелкими? Вы несете чушь, и более того, сомневаюсь что только в этом месте.

>Что IB быстр, документирован, надежен и беспроблемен в эксплуатации?
да, все перечисленное, и именно у IB все хорошо с документацией. Вот у FB - плохо.

>чтобы поделиться своим опытом с IB/Firebird.
нет у Вас никакого опыта. Мало того что Вы откуда-то чужие слухи начинаете транслировать, так еще и "опыт" этот имели 11 лет назад. Да, InterBase 5.6 на текущий момент - полное говно, по сравнению с IB 2007/2009 или последними версиями Firebird. А 11 лет назад был вполне ничего.

>Ещё раз, не отвлекаясь, повторяем мантру все вместе
К чему эти злобствования, которые совершенно не соответствуют действительности?
Вы как эмигрант, уехавший из СССР до 1991 года - все коммунисты за углами мерещатся.

[gsbelarus.livejournal.com]

можно было бы и обновить:

"если сервер нормальный (хотя бы с ОЗУ 1-2 гигабайта). Даже для рабочих станций сейчас рекомендуемый размер памяти - 512 мегабайт..."

[interbase.livejournal.com]

>тупо работает в 5 раз медленнее чем на аналогичных машинах.
включите Write Cache у контроллера диска. Выучите наконец эту область администрирования железа, освойте perfmon, что-ли.

[interbase.livejournal.com]

>А вы паясничаете, по сути.
сейчас выясним, кто паясничает. Предлагаю посмотреть процедуру и ее blr. И найти там вкомпилированный план запроса.

create PROCEDURE a
as
declare variable i integer;
begin
select emp_no from employee
where EMP_NO = 1
into :i;
end;

blr_version5,
blr_begin,
blr_message, 1, 1,0,
blr_short, 0,
blr_begin,
blr_declare, 0,0, blr_long, 0,
blr_assignment,
blr_null,
blr_variable, 0,0,
blr_stall,
blr_label, 0,
blr_begin,
blr_begin,
blr_for,
blr_singular,
blr_rse, 1,
blr_relation, 8, 'E','M','P','L','O','Y','E','E', 0,
blr_boolean,
blr_eql,
blr_field, 0, 6, 'E','M','P','_','N','O',
blr_literal, blr_long, 0, 1,0,0,0,
blr_end,
blr_begin,
blr_assignment,
blr_field, 0, 6, 'E','M','P','_','N','O',
blr_variable, 0,0,
blr_end,
blr_end,
blr_end,
blr_end,
blr_send, 1,
blr_begin,
blr_assignment,
blr_literal, blr_short, 0, 0,0,
blr_parameter, 1, 0,0,
blr_end,
blr_end,
blr_eoc

[interbase.livejournal.com]

форматирование убилось, к сожалению.