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

[metaclass]

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

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

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

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

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

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

Comments

[interbase.livejournal.com]

>вторичны дальше некуда (то что есть неудачно дернуто с оракла)
не смешите. InterBase разрабатывался человеком из DEC, разработка велась параллельно с DEC RDB, так что никакой вторичности здесь нет. Просто в те времена идеи были одни и те же, и все архитекторы СУБД так или иначе знали друг друга, и даже бухали вместе.

>Слава богу в 1999 году я с этими бредо-СУБД закончил.
история Вам противоречит. Раньше IB был одним версионником, теперь версионников полно - Оракл, PostgreSQL, и даже MS SQL.

[enternet.livejournal.com]

Уважаемый Дмитрий! Если бы я имел честь общаться с вами эдак а 1998 году, я бы наверное обосрался от счастья. Уж простите за прямоту. Я тогда вообще мало-мальски грамотным специалистам в рот смотрел.

Но теперь другие времена. Не надо петь военных песен. Версионность, не версионность. История, не история. Это маркетинговый шит. Главное - что же происходит на самом деле в момент применения. А на деле IB и клоны - это самые медленные СУБД из мной пользованых. И честно сказать, ещё и самые неудобные в программировании.

Наверное что-то поменялось за 10 лет, может быть сейчас продукт стал стабильнее и гард не нужен? Может быть в нем отказались от сторонней dll со строковыми функциями и мы можем иметь всё это счастье на и линуксе? Может стало возможным использовать хинты, а не переписывать план целиком с жестко заданными именами индексов? Может планы перестали быть вкомпилированы намертво в п-код (или как его там)? И нам не нужно перекомпилировать процедуры с ростом количества хранимых данных? И после апдейта большой таблицы нам не нужно больше ждать полчаса на первом селекте? В конце концов, вопрос в лоб - оптимизатор поумнел? Или по прежнему в трех индексах заблудиться может? А сколько помнится геморроя с бакапом было. Типа бакап есть, а рестор его отработать не может.

Блин, некрофилия какая-то.

[metaclass.livejournal.com]

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

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

С бэкапами там таки да, были уже срачи на эту тему в гуглогруппе.

[restoran.livejournal.com]

>я про такую шизу не слышал, надо срочно уточнять
>у разработчиков, потому что есть вероятность, что это сильно влияет на наш софт

да да, бегите, срочно уточняйте!
http://www.ibase.ru/devinfo/ibmyths.htm
пункт 9. документ не менялся уже много лет (5-6).

[gsbelarus.livejournal.com]

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

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

[restoran.livejournal.com]

>Но теперь другие времена. Не надо петь военных песен.
да пофиг. Вы сказали про "вторичность", я ответил. Про вторичность замнем?

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

В общем, наезд из тьмы прошлого не прошел. :-)

[enternet.livejournal.com]

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

Маркетинговый шит это маркетинговый шит.

Процедуры можно не перекомпилировать, будет работать, но поскольку план намертво вкомпилирован в bsql, вы будете сильно удивлены изменению скорости работы, если сделаете это. Что ещё смешнее, помнится даже порякок компиляции влиял на конечный результат. И уж совсем удивительно, что вы этого не знаете.

Евгений Ваганович, перелогиньтесь там прям из лужи.

[interbase.livejournal.com]

>Интербейз конкретно стянул некоторые неудачные решения, например генераторы.
не вижу генераторов в Оракле. Доказательства про "стянул", пожалуйста, с перечнем неудачных решений.
Генераторы, кстати, вполне даже очень удачные. Не хуже sequence или @identity, а порой даже и лучше.

>Процедуры можно не перекомпилировать, будет работать, но поскольку план намертво вкомпилирован в bsql
да хватит уже позориться, план никогда не был вкомпилирован в BLR, ни в одной версии IB/FB.

>Евгений Ваганович, перелогиньтесь там прям из лужи.
посылаю обратно.

[vp.livejournal.com]

Генераторы, кстати, вполне даже очень удачные. Не хуже sequence или @identity, а порой даже и лучше.

Я вставлю 5 копеек. Генераторы в ФБ - штука наимощнейшая и очень приятная в использовании. Например, у нас были задачи, когда мы генерировали уникальные ключи в контексте "предприятие - подразделения", чтобы они никогда не пересекались друг с другом. В этом плане генераторы ФБ были спасением.

[norritt.livejournal.com]

Подписываюсь. Когда потом на MS SQL идентити переделывали — геморрою было огого

[enternet.livejournal.com]

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

[vp.livejournal.com]

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

[metaclass.livejournal.com]

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

[enternet.livejournal.com]

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

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

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

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

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

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

[metaclass.livejournal.com]

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

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

[enternet.livejournal.com]

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

[interbase.livejournal.com]

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

[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 года - все коммунисты за углами мерещатся.

[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]

на всякий случай, если не хотите читать blr:
http://www.ibase.ru/devinfo/ibmyths.htm
пункт 9
9. Скомпилированные процедуры хранят планы запросов

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

Добавлю, что да, у IB/FB есть недостатки, как и у любой другой РСУБД. Но. Если Вы работали с этой СУБД 10 лет назад, и не знаете НИЧЕГО о том, что за эти 10 лет поменялось, Вам не стоит
- транслировать старые баги или особенности на текущие версии
- думать, что за 10 лет ничего не изменилось

И, когда будете повторять ту свою "мантру", обязательно прибавляйте, с какой версией IB Вы работали, и как давно это было. А то может случиться, что Ваш оппонент будет очень даже в курсе свежих IB/FB, и в результате Вы будете выглядеть бледно.

Я если позволяю себе высказывания в адрес других РСУБД, то перед этим обычно проверяю документацию и форумы.

[theiced.livejournal.com]

а генераторы - это такие секвенсы, только с блэкджеком?

[enternet.livejournal.com]

Типа да, но дело не в этом - я идею генераторов/сиквенсов вообще считаю неудачной by design. Непонятно зачем тянуть себе плохие решения.

[metaclass.livejournal.com]

Не, идея хорошая, их можно использовать для всяких порочных целей, кроме идентификаторов.
Но мне больше всего понравилось, что в PGSQL есть тип serial который автоматом создает сиквенс и вешает его на поле таблицы для заполнения.

[metaclass.livejournal.com]

Почти одно и тоже.

[golosptic.livejournal.com]

Нет, про вторичность не замнем. Оракл был раньше.
Вне зависимости от.
Аппелировать ко вторичности на таких временнЫх промежутках - смешно чуть менее, чем полностью.
Разница между 76 и 81ыми годами прошлого века в 2010 не может быть серьёзным аргументом в спорах о технологиях.