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

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

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

[metaclass.livejournal.com]

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

[metaclass.livejournal.com]

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

[enternet.livejournal.com]

Т.е. голден-софтвер живой ещё? Долгожители, молодцы. Ностальгия прям, «Анжелика», «Брест» )

[metaclass.livejournal.com]

Живой, живой, мы с их работающими продуктами сталкиваемся у клиентов иногда.

[vp.livejournal.com]

Вот про "дело вкуса" - это интересно. Есть же де-факто стандарты. Никогда не понимал зачем на этой почве велосипед?

И по поводу стороннего софта для ssl. Можно привести пример рекомендуемого решения?

[vp.livejournal.com]

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

[enternet.livejournal.com]

Страшен был объем исходников и время работы этого компонента )

Тогда-то я проникся, а сейчас за такое я бы руки по самые гланды оторвал. Я вообще с некоторых пор крайне подозрительно отношусь к объему исходных текстов. Т.к. существует такая категория программистов, которая просто заваливает всех вокруг объемом кода. А ведь его потом сопровождать нужно. Причем глянешь в такой код - волосы дыбом, мой рекорд - в 20 раз недавно чужой модуль ужал.

[vp.livejournal.com]

Ищо какой живой. Они ряд больших заказчиков заимели, и живут - не тужат.

[vp.livejournal.com]

Если разработка велась году так в 1998...2000, то особых альтернатив и не было. Ну можно было в HTML выгнать. Но им 100% была нужна точная печать форм на бумагу, вот потому РТФ и родился :)

[enternet.livejournal.com]

Ну почему же, альтернатива была. Excell & Word через COM. Вполне быстро и надежно, если уметь готовить. А точных требований к размеру полей документов тогда и не было.

[metaclass.livejournal.com]

С excel и word через COM имеются всякие заморочки, от их отсутствия на рабочей машине, до плющей при изменении версий офиса. И вроде не так уж быстро оно работает, ручная генерация RTF по идее быстрее.

[restoran.livejournal.com]

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

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

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

[restoran.livejournal.com]

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

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

[restoran.livejournal.com]

>Никогда не понимал зачем на этой почве велосипед?
консольные утилиты InterBase возникли в 1985 году. Какой тогда был нафиг posix-стандарт? Тогда и SQL-то в СУБД не было. А сам Posix появился (!) в 1988 году.

>Можно привести пример рекомендуемого решения?
самый давно и широкоизвестный - zebedee.

[enternet.livejournal.com]

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

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

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

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

[interbase.livejournal.com]

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

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

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

[interbase.livejournal.com]

в firebird.log в основном выводятся ошибки. он для этого и предназначен. а не для аудита. Аудит предназначен для тюнинга при разработке, или при отладке в prodiction, в основном логе ему делать нечего.

[vp.livejournal.com]

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

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

[vp.livejournal.com]

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

MyCoolServer (Server) Wed Jan 20 14:11:54 2010
INET/inet_error: read errno = 10054

ВСЁ

Скажите, что админ может по такому логу диагностировать? Понятно, что 10054. Но ведь оно работало УЖЕ в контексте хоста "с того конца". Неужели тяжело дописать хотя бы какой адрес овалился?

То есть я поддерживаю мнение что логи все-таки "не от мира сего".

[interbase.livejournal.com]

ошибка с номером означает, что она пришла "извне", т.е. является реакцией внешнего окружения на действия FB. Но насчет того, что в данном сообщении не пишется ip и прочее - безобразие. Я сам не понимаю, почему в Firebird нет того, что уже давно есть в Interbase

IBASE (Client) Tue Mar 24 20:33:46 2009
INET/inet_error: read errno = 10054 client host = UNKNOWN connection name = localhost user name = UNKNOWN server port number = 3050

[interbase.livejournal.com]

http://tracker.firebirdsql.org/browse/CORE-2493

[norritt.livejournal.com]

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

[volodymir-k.livejournal.com]

> Неужели тяжело дописать хотя бы какой адрес овалился?

А что, Интербейз разве не опенсорсили? Или стесняетесь билдить сами?

[vp.livejournal.com]

На фоне обилия текущей работы билдить сервер баз данных - это вот именно та мелочь, которой не хватало до полного счастья :)