metaclass: (Default)
metaclass ([personal profile] metaclass) wrote2010-03-03 11:51 am

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

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

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

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

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

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

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

[identity profile] metaclass.livejournal.com 2010-03-04 02:15 pm (UTC)(link)
Invalid object - это что в виду имеется?

[identity profile] osdm.livejournal.com 2010-03-04 03:46 pm (UTC)(link)
Если добавляешь или удаляешь поле в таблице, от которой зависят вьюшки и хранимые процедуры, от которых в свою очередь зависят другие вьюшки и хранимые процедуры и т.п., то в Firebird-е приходится сначала удалять все зависимые объекты, изменять таблицу, а потом создавать все зависимые объекты заново. В Oracle вместо этого зависимые объекты помечаются признаком "Invalid" (не всегда, обычно, если после изменения объекта их невозможно скомпилировать, например, если удалили поле, на которое реально была ссылка во вьюшке). Их можно перекомпилировать, и они снова станут валидными. Благодаря этому внесение изменений в базу резко упрощается. У нас софтина сама обучена при необходимости вносить изменения в схему БД, поэтому для Firebird пришлось ее учить пересоздавать все дерево зависимостей.

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

[identity profile] metaclass.livejournal.com 2010-03-04 05:10 pm (UTC)(link)
А, с зависимостями это мрак, да. Сложновато переделывать бывает.

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

[identity profile] osdm.livejournal.com 2010-03-04 09:41 pm (UTC)(link)
В теории, наверное, не требуется, но на практике почему-то приходится всех с базы выгонять. Где у кого какой объект затронут - установить не удается. Может быть, конечно, где-то в нашей софтине проблема, но с ораклом при аналогичной схеме использования проблем нет.

[identity profile] metaclass.livejournal.com 2010-03-05 08:30 am (UTC)(link)
А что происходит если не выгнать?
Я помню несколько вариантов:
1) в какой-то версии просто не давало менять занятые SP и ругалось сообщением. Сейчас просто пишет в лог.
2) сейчас если менять объект, прямо сейчас используемый в незавершенной транзакции - вроде тоже ругается
3) на классике не сразу обновляется кэш метаданных, во всяком случае, другие процессы сразу изменения не видят (давно не перепроверял, может уже и исправили).

Вообще ключевой аспект, что достаточно делать транзакции короткими и всегда закрывать их (commit или rollback) - тогда никаких проблем нет.