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

[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 году я с этими бредо-СУБД закончил.

[gsbelarus.livejournal.com]

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

[metaclass.livejournal.com]

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

[enternet.livejournal.com]

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

[metaclass.livejournal.com]

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

[enternet.livejournal.com]

Ой, какие лица )
этож знатные извращенцы ) Я как их RTF-генератор отчетов вспомню, так вздрогну. Зверь. Мегабайт исходников на дельфи.

[metaclass.livejournal.com]

Ай, тут я сам грешен, каких только шизовелосипедов я на дельфи не делал. И продолжаю делать, только уже на C# и всякой функциональщине.

[metaclass.livejournal.com]

О йопт, он еще и директор голден-софтвера

[vp.livejournal.com]

А что там страшного было? RTF вроде как православен. Вот если бы они Excel запускали и отчеты бы делались в нем... :)

[enternet.livejournal.com]

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

[metaclass.livejournal.com]

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

[enternet.livejournal.com]

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

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

А время - это самое дорогое что есть у человека, его нельзя купить. Поэтому я считаю пропагандистов IB/FB в некотором роде врагами рода человеческого )

[denisioru.livejournal.com]

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

[metaclass.livejournal.com]

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

[denisioru.livejournal.com]

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

[gsbelarus.livejournal.com]

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

см. утилита nbackup

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

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

[theiced.livejournal.com]

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