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

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

Interbase и её клоны честно говоря очень хреновые СУБД. Мало того, что аскетичны дальше некуда (даже строковых функций родных нет), вторичны дальше некуда (то что есть неудачно дернуто с оракла) так ещё и проблемы с производительностью серьёзнейшие. Нагло прикрываются "передовой архитектурой" - типа у нас блокировок по чтению нет, а то что сборка мусора через SELECT сделана, т.е. тормоза на полчаса после любых массовых обновлений - это, по-моему, хуже блокировок.

Слава богу в 1999 году я с этими бредо-СУБД закончил.

[zamotivator.livejournal.com]

Там нету кубов и windows functions появились буквально вчера, но не позавчера.
Но в целом PostgreSQL рулит и бибикает

[theiced.livejournal.com]

и впредь запомните - надо всегда слушать мудрого айседа ;]

[metaclass.livejournal.com]

Кубы в базах меня бесят, уж извините :)
А вот windows functions в Firebird и вообще не пахнет :)

[theiced.livejournal.com]

такс - а вот на что стоит обратить пристальное внимание:

1. при смене мажора придётся делать дамп/рестор. увы.
2. твикинг перфоманса под конкретный случай - довольно нетривиальная задача. с ним лучше идти на #postgres@freenode
3. _иногда_ оптимизатору запросов евойному сносит напрочь крышу (ну я стабильно раз в год натыкаюсь на случай когда вполне себе приличный запрос работает на порядки медленее чем должен, непонятно почему).

[alexott.livejournal.com]

ну твикинг перформанса почти у всех баз - нетривиальная задача. я все время вспоминаю как работают оракловые админы :-)

[metaclass.livejournal.com]

Оптимизатор это фетишистская тема, оно везде плющится.

[oldmann.livejournal.com]

ребе, неужэли ви раньше постгриса не видели?

[inhate.livejournal.com]

А как там сделать GRANT all on dbname.* без самописных вуду-функций?

[zamotivator.livejournal.com]

Не знаю, я ж ядро выполнения запросов оцениваю, а не прочие плюшки, как бэ.

[gsbelarus.livejournal.com]

c 99-го много что изменилось. так что не пишите ерунды про отсутствие функций и сборку мусора через селект.

[metaclass.livejournal.com]

Таки сборка мусора сейчас жеж вроде комбинированная, т.е. и на фоне и через селект?

[gsbelarus.livejournal.com]

А вот windows functions в Firebird и вообще не пахнет :)

http://asfernandes.blogspot.com/2010/01/window-functions_19.html

[theiced.livejournal.com]

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

[theiced.livejournal.com]

ах да - рекомендую книжечку-со-слоником заиметь. она прилично устарела, но читается как художественная (если сикль знаешь) за пару вечеров и даёт неплохой кикстарт.

[metaclass.livejournal.com]

We have promissed very basic support for window functions in Firebird 3, which was the OVER () clause using the current aggregate functions.

Печаль. :)

[nivanych.livejournal.com]

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

[theiced.livejournal.com]

да - но её ОЧЕНЬ много. а книжко клёвэ.

[interbase.livejournal.com]

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

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

[interbase.livejournal.com]

1. аудит и т.п. есть теперь в 2.5. В обычном логе аудиту делать нечего
2. кому как
3. тоже дело вкуса. вариантов аутентификации два
4. используй сторонний софт.
5. документация PGSQL часто грешит враньем. Хотя да, у FB с документацией есть наследственные проблемы. Я уже задолбался про них объяснять.

[metaclass.livejournal.com]

По первому пункту - я до сих пор не понимаю, в чем сложность прикрутить с десяток настраиваемых и выключенных по умолчанию параметров типа "что выводить в firebird.log". Т.е. это ж даже не архитектурные моменты, не формат бинарников, т.е. не поломается ничего (главное чтобы на мьютексе охраняющем этот лог каких-нибудь дедлоков не возникло) :)
Содержимое лога в 90% процентов случаев бесполезно.
"SERVER2 (Server) Thu Jan 21 22:56:53 2010 INET/inet_error: read errno = 10054"

По второму пункту - в современной индустрии уже не "кому как" а "чем ближе к общепринятому тем лучше".

По третьему - настройка аутентификации в hba.conf выглядит намного более правильной, чем два варианта в fb(это родная+виндовская, как я понимаю?)

Сторонний софт у fb хорош, не спорю. Но, имхо, это и количество этого софта - показатель что в исходном комплекте сервера чего-то не хватает.

Ситуация же с документацией у FB страшна. Большую часть известных заморочек пришлось узнавать на ibase.ru и в гугло-группе. Бессвязные же release notes и текстовые доки в составе инсталлятора хоть и содержат новые моменты, но для целенаправленного изучения не пригодны.

[enternet.livejournal.com]

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

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

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

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

[enternet.livejournal.com]

Кстати, раз уж тут вылез господин Кузьменко, скажите, а ваша фамилия не случаем не Киреев? А то больно ник знакомый. Golden Software of Belarus?

[metaclass.livejournal.com]

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

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

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

[metaclass.livejournal.com]

Они, гедымин то бишь :)
Насчет фамилие не знаем.