Вы конечно, меня извините,
Mar. 3rd, 2010 11:51 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassно PostgreSQL с первого взгляда выглядит более правильной СУБД чем Firebird.
1) Логи, много понятных логов. Небо и земля, по сравнению с ничего не значащим бредом, которым firebird.log заполнен чуть более чем полностью. Т.е. там даже нет возможности включить что нибудь вроде "протоколирование доступа к базе", не говоря уже о запросах, итд.
2) Читабельный вывод консольных утилит. Posix-командная строка этих самых утилит. Вменяемые параметры их же.
3) Несколько вариантов аутентификации, управление аутентификацией c детализацией по адресам-маскам, именам базы, юзеров
4) доступ через ssl.
5) И наконец, ключевой аспект: документация. 2100 страниц нормальной понятной хорошо структурированной документации, доступной в виде PDF с официального сайта. В отличие от, блядь, документации по Interbase 6 на которую до сих пор ссылаются на сайте FB и потока сознания разработчиков в виде quick start quide и release notes.
1) Логи, много понятных логов. Небо и земля, по сравнению с ничего не значащим бредом, которым firebird.log заполнен чуть более чем полностью. Т.е. там даже нет возможности включить что нибудь вроде "протоколирование доступа к базе", не говоря уже о запросах, итд.
2) Читабельный вывод консольных утилит. Posix-командная строка этих самых утилит. Вменяемые параметры их же.
3) Несколько вариантов аутентификации, управление аутентификацией c детализацией по адресам-маскам, именам базы, юзеров
4) доступ через ssl.
5) И наконец, ключевой аспект: документация. 2100 страниц нормальной понятной хорошо структурированной документации, доступной в виде PDF с официального сайта. В отличие от, блядь, документации по Interbase 6 на которую до сих пор ссылаются на сайте FB и потока сознания разработчиков в виде quick start quide и release notes.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-03-04 12:25 pm (UTC)http://www.ibase.ru/devinfo/ibmyths.htm
пункт 9
9. Скомпилированные процедуры хранят планы запросов
Ничего подобного (если только план запроса не задан явно). Данный миф основан на том, что процедура или триггер после первого вызова (и именно в этот момент вычисляются планы запросов, которые в процедуре написаны) остается в кэше метаданных до тех пор, пока все клиенты, вызывавшие эту процедуру, не отсоединятся. В этом случае действительно, пока процедура находится в памяти, планы запросов не меняются, даже если изменится статистика используемых планами индексов.
Добавлю, что да, у IB/FB есть недостатки, как и у любой другой РСУБД. Но. Если Вы работали с этой СУБД 10 лет назад, и не знаете НИЧЕГО о том, что за эти 10 лет поменялось, Вам не стоит
- транслировать старые баги или особенности на текущие версии
- думать, что за 10 лет ничего не изменилось
И, когда будете повторять ту свою "мантру", обязательно прибавляйте, с какой версией IB Вы работали, и как давно это было. А то может случиться, что Ваш оппонент будет очень даже в курсе свежих IB/FB, и в результате Вы будете выглядеть бледно.
Я если позволяю себе высказывания в адрес других РСУБД, то перед этим обычно проверяю документацию и форумы.