вышел Firebird 2.0

Я лично для этого писал модули к FB - лучше б я умер. На постгресе такое уже тридцать раз сделано.

>недостатки, может быть - но у fb не недостатки а муйня какая-то куда не ковырни. на счет развивается - не смешите, ничего существенного в билижайшие 3-5 лет там даже не планируется изменить.

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


спор пустой. ваша воля не использовать софт, а жить ему или в топку, ой не вам решать, ой не вам... можешь сколько угодно кричать "в топку", народ просто посмеётся очередному пионерскому возгласу. =)

Описаны были не проблемы. Описаны были хотелки. Еще раз спрашиваю - на чем эти хотелки _реализованы_. Или еще нет?

А насчет "как представляешь" - нормально представляю. Суппортю уже четвертый год систему, как раз с бухгалтерскими данными (и не только) - платежи населения, примерно полмиллиона лицевых в сумме. Правда специфика такая, что 10 минут "лежания" системы - фигня. В принципе, вполне устраивает даже "вчерашний" бэкап, если грохнется - тетки перевведут за два часа, все, что было потеряно, с первички. Хотя за эти четыре года помню от силы десяток случаев, когда вообще приходилось что-то поднимать из бэкапа (еще раз напоминаю - 17 баз), причем не по причине сбоев СУБД, а по другим - винт "обсыпался", по запарке оператор "не то" обнулил по паре тысяч лицевых и т.п.

Невосстановимых бэкапов НЕ ВИДЕЛ, хотя каждый месяц мне их пару десятков присылают для контроля...

Т.е. для каждой задачи СУБД надо подбирать с умом. Если у тебя онлайн биллинг, не терпящий минутного простоя - firebird не для тебя. Ищи что-то, поддерживающее FailOver clustering. А для моих задач - вполне себе система.

Grue

> вот в том то и дело, что ты занимаешься ковырянием, а у других оно > просто работает годами, и всё ок.

Некоторые программы на фортране работают уже с пол века (я одну с 35 летним стажем знаю - ее до сих пор пользуют). Но это вовсе не повод сейчас писать на f77.

> спор пустой. ваша воля не использовать софт, > а жить ему или в топку, ой не вам решать

Не ему конечно, но разговор то о сравнении с другими БД. Так что "в топку" следует читать как "заметно уступает по возможностям".

даёшь Phoenix 2.0 к следующему викенду!

> Описаны были не проблемы.
Проблемы:

1)Ничего что в программе было помеченно как успешно сделанное и на что 
был чек напечатан или бумага выдана, или в накладной была подпись 
поставлена пропасть уже не может(кроме как изза изв. вулкана,падения 
кометы,или второго пришествия).
2)При падении одного из серверов ситема должна как ни в чем не бывало
работать дальше

> В принципе, вполне устраивает даже "вчерашний" бэкап, если грохнется - > тетки перевведут за два часа, все,

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

> Невосстановимых бэкапов НЕ ВИДЕЛ, хотя каждый месяц мне их пару 
> десятков присылают для контроля

Пол года работы на 16 точках без проблем(пока).

> Т.е. для каждой задачи СУБД надо подбирать с умом. Если у тебя 
> онлайн биллинг, не терпящий минутного простоя - firebird не для 
> тебя. Ищи что-то, поддерживающее FailOver clustering. А для моих 
> задач - вполне себе система.

А когда наступит время билинг писать - ты скажеш "а ну его нафик мои 
знания и опыт работы с фаерб. час выучу постгрес и буду на нем делать"
- так значит? В добавок опять непонятно зачем лишние проблмы, когда 
есть постгрес в котором их будет намного меньше. Разве что привычка.
Кстати,еше раз, а как ошибки править - если упадет. По креш 
дампам? Уверяю - замучаешся.

> Еще раз спрашиваю - на чем эти хотелки _реализованы_. Или еще нет?

Хотелки(только первая - логи) реализованы как расширения firebird 1.5. В постгресе давно есть. Но после "бли с ЭТИМ я больше за него ни сяду 
никада. 

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

Зря зря. Вменяемый лог + авк могут спасти пару тройку часов работы приличного коллектива. И зарплату этим людям платят не менше чем админу, не желающему копаться в логах. Сайбейс с этой точки зрение был просто песней.

> Для восстановления базы я делаю nbackup раз в час, этого мне достаточно.

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

> Сайбейс с этой точки зрение был просто песней.

Почему "был"? На днях EBF к SA10 вышел, ребята не спят.

> 2)При падении одного из серверов ситема должна как ни в чем не бывало работать дальше

Ну я же и говорю - кластер тебе нужен. А мне - не нужен.

> Я говорю о серьезном софте - когда два часа простоя системы - потеря больших денег

Если это действительно вопрос _больших_ денег - почему ораклу не купили?

> А когда наступит время билинг писать - ты скажеш "а ну его нафик мои знания и опыт работы с фаерб. час выучу постгрес и буду на нем делать

Лишних знаний не бывает, опыта - тоже. Разобравшийся в FB - разберется и в постгресе, если приспичит. Не вижу никакой проблемы.

> Хотелки(только первая - логи) реализованы как расширения firebird 1.5

В двойку их включили? Или не посылал? Или сказали - "фу... пионерщина"? ;-)

Grue

>Описаны были не проблемы. Описаны были хотелки. Еще раз спрашиваю - на чем эти хотелки _реализованы_. Или еще нет? А насчет "как представляешь" - нормально представляю. Суппортю уже четвертый год систему, как раз с бухгалтерскими данными (и не только) - платежи населения, примерно полмиллиона лицевых в сумме. Правда специфика такая, что 10 минут "лежания" системы - фигня. В принципе, вполне устраивает даже "вчерашний" бэкап, если грохнется - тетки перевведут за два часа, все, что было потеряно, с первички. Хотя за эти четыре года помню от силы десяток случаев, когда вообще приходилось что-то поднимать из бэкапа (еще раз напоминаю - 17 баз), причем не по причине сбоев СУБД, а по другим - винт "обсыпался", по запарке оператор "не то" обнулил по паре тысяч лицевых и т.п. Невосстановимых бэкапов НЕ ВИДЕЛ, хотя каждый месяц мне их пару десятков присылают для контроля... Т.е. для каждой задачи СУБД надо подбирать с умом. Если у тебя онлайн биллинг, не терпящий минутного простоя - firebird не для тебя. Ищи что-то, поддерживающее FailOver clustering. А для моих задач - вполне себе система.

У меня телефонная система на ФБ крутится, 5 минут простоя - и директор лично заходит в кабинет узнать что и почему.. :-( Изменить базу нельзя - сторонняя разработка. А у интерфеса есть глюк из-за которого если базу раз в неделелю не отресторишь - то будет этот самый крах БД (было не раз), когда даже залезть туда не получается. Вот только в последних версиях ФБ эти ошибки нивелированы, чему я очень рад.

По моему - таки не плохая БД. Тем более что очень легко программируется с использованием IBPP . Больше всего мне в нем нравится концепция доменов - чего так не хватает в оракле.

Ну наконец-то.. Но лучше поздже, чем никогда..

> Если это действительно вопрос _больших_ денег - почему ораклу не купили?

Потому как 
1) оракл бы удорожил систему 
2) там никто поддерживать его не будет(система установлена за 3000км).
3) Начинали писать любители firebird + пред. версия была не нем 
написана.

> Лишних знаний не бывает, опыта - тоже. Разобравшийся в FB - разберется 
> и в постгресе, если приспичит. Не вижу никакой проблемы

Разберется конечно. Но мне времени потр. на изучения нутра ФБ
откровенно жалко. Я бы лучше потратил его на что-нить другое,
тем более что после этого FB больше не пригодился. А по приходу 
FB3 все полученные знания и вовсе пойдут прахом - т.к. его пол. 
переписать на С+ собрались.(Даже тогда я свои задачи на постгресе
делал потому как мой любимый питон встроенный есть )).

> Или сказали - "фу... пионерщина"? ;-)

Так точно )). А оно и на самом деле криво было
(и есть криво) - сделано под конкр. задачу.

>А в чем смысл ведения лога транзакций в версионной архитектуре?

Т.н. redo-log. Штука хорошая, но не сказать чтоб жизненно необходимая. Скажем на селективные процедуры или отсутствие блокировок по чтению я бы ее не променял - ИМХО эти фичи файра куда как пользительнее. :)

> Т.н. redo-log. Штука хорошая, но не сказать чтоб жизненно необходимая

Для востпроизведения ошибок - самая что ни на есть жизненно необходимая.

> отсутствие блокировок по чтению

А в какой это базе они есть? В MySQL,Postgres,SQLite 
точно все в порядке.

>Удивительно, этой бесполезной СУБД пользуются куча компаний. Лохи они все...
>BigSerpent

Ути пуси - вон Access или FoxPro пользуется в сотни (в то и в тысячи) раз больше компаний - и что, оне от жтого стали _хорошими_ СУБД???? :)

> если происходит сбой запарываются оба файла и базу относят на помойку

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

> на счет SQL, знаете что КАК это чудо исполнит такие запросы ?

Знаем, причем уже лет дохренадцать как. Равно как и то, почему оно так работает и каким образом это обходится. А у вас похоже за это время так и не появилось серьезных аргументов против FB кроме древних и уже сто лет как задокументированных архитектурных особенностей. 

Для особо не умеющих читать

> А ну поведайте-ка, что это должен быть за сбой, который похерит до > невосстановимого

До восстановимого, но outdated т.е. без последних изменеий.

А с логом ничего не будет - он на другой машине.

> А у вас похоже за это время так и не появилось серьезных аргументов

Читаем посты выше там уже кучу раз писалось

> До восстановимого, но outdated т.е. без последних изменеий.

Нет минуточку! Изначально было "база в мусор". Давайте уж придерживаться одного варианта развития событий.

> А с логом ничего не будет - он на другой машине.

И как это нас должно уберечь от нашей супермегагиперошибки, сносящей все в мусор одним взмахом мизинца?

> Читаем посты выше там уже кучу раз писалось

Нету там ни фига. То, что перечислено - хоть и "вкусно", но по большому счету никому совершенно не приспичило.

УРА! Ораклу капец! :)

Сначала винда подохла, а теперь скоро оракл помрёт - неделя капецев началась :)

> Нет минуточку! Изначально было "база в мусор". Давайте уж 
> придерживаться одного варианта развития событий.

Ну пусть будет в мусор - это ничего не меняет.

> И как это нас должно уберечь от нашей супермегагиперошибки, сносящей 
> все в мусор одним взмахом мизинца?

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

> Нету там ни фига. То, что перечислено - хоть и "вкусно", но по 
> большому счету никому совершенно не приспичило.

Афигеть. Так может тебе и sqlite хватит? К нему 
сетевой сервер прикрутили. Веесеело(с)Подереянський.
У меня много знакомых про шаблоны и классы.
так говорят - а нафик нам все это нам фортрана хватает.
Для поделок может и хватает.

> Но даже в случае ошибки - ее сразу заметят - т.к. прога сдохнет. > А после перзапуска база будет в состоянии "сразу перед падением". > Никаких незарег. накладных не выписано денег не переведено и т.д.

Собственно откуда возьмутся незарегистрированные накладные или деньги пропадут, если только девелопер не накосячил с управлением транзакцией? После падения база (если только хард не помер) будет в состоянии последней зафиксированной транзакции. Или вам журнал поможет что-то сверх этого восстановить? Незакомиченные изменения? ;)

> Ну пусть будет в мусор - это ничего не меняет.

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

> Афигеть. Так может тебе и sqlite хватит?

А шо, сервер без единого кэша в SMP и redo-лога - это автоматически аналог sqlite? Ну-ну, надо ихним разработчикам посоветовать чтоб прикрутили их к своему изделию - тогда оно наверняка станет таким же крутым и бессмертным, как великий Постгрес! :)

>Собственно откуда возьмутся незарегистрированные накладные или деньги пропадут, если только девелопер не накосячил с управлением транзакцией? После падения база (если только хард не помер) будет в состоянии последней зафиксированной транзакции. Или вам журнал поможет что-то сверх этого восстановить? Незакомиченные изменения? ;)

i skolko ti smogesh tranzakcii gonyat na bazze s vklychenim sync`om ? ili dlya FB (sydya po postam vishe tak ono i est) nety ponyatiya effectivnogo ispolzovaniya pamyati ? ili FB tranzakzii ne kommitit SRAZY na vint ? togda posle padeniya ti polychish neprotevorechivoe sostoyanie no 50% bez poslednich tranzsaczii. A esli FB postoyano sync/flash to skolko ti ich mogesh sdelat v sekyndy ? skolko blokov mogesh pomenyat v sekyndy ?

Redo - ne tolkko ydoben (ob etom vishe) no polezzen dlya Skorosti ...

> 1) оракл бы удорожил систему

Т.е. деньги все-таки не настолько большие ;-)

> Но мне времени потр. на изучения нутра ФБ откровенно жалко

А зачем ты лазил в нутро?

{лирическое отступление} Был у меня один приятель, он когда в игрушке не мог уровень пройти - запускал ее под отладчиком, пару дней трахался, находил, где там какие переменные, и добавлял себе кучу жизней. Это я так, в порядке аналогии ;-)

Grue

как я раз, что забросил эту поделку еще во время Interbase 5.5 :)

а качестве примера работоспособности -- одно наше отделение в области заключили договор на мелкую программку с последующим обслуживанием на fb 1.5 + VC6 и даже свой комп для этого предоставили, правда без упсы. Как-то скакануло у них электричество, и 2 недели работы в этой програмулине ушли -- эти сопроводители backup делали за 2 недели до этого, а сами страшно кричали что б их машину ни кто не трогал, а то все испортят :D

> Redo - ne tolkko ydoben (ob etom vishe) no polezzen dlya Skorosti ...

А он как, каждую запись сразу на диск пишет? Тогда это просто дополнительный sync, и на скорость повлияет только в минус.

А если нет - где тогда надежность?
Насчет удобства не спорю, может, и правда удобно кому...

Grue

> а качестве примера... ...комп... ...без упсы... ...backup делали за 2 недели...

Это да, весьма показательный пример! :) :) :) И виноват в ситуации конечно не кто-нибудь, а сервер Firebird. Предлагаю вычесть у него, мерзавца, 50% из премиальных! :) :) :)

> Как-то скакануло у них электричество, и 2 недели работы в этой програмулине ушли -- эти сопроводители backup делали за 2 недели до этого

Как говорится, кто не далает бэкап - ССЗБ.

У нас вон в одном филиале сервер с FB 1.0.3 в качестве СУБД просто сперли. Высадили окно и фюить ;-)

Не было бы в сейфе диска со позавчерашним бэкапом (вчерашний остался на компе, отложили на утро списать на болванку), забивали бы ручками c момента основания ;-)

{это шутка. бэкап на 1 число каждого месяца можно одолжить у меня ;-)}

Grue

> А у меня, например, под Firebird'ом сейчас по области 17 баз, из них самые крупные вот-вот за 10 гиг перевалят

Уже не у меня, но только одна из табличек в 3 раза больше. Под постгресом.

>> А у меня, например, под Firebird'ом сейчас по области 17 баз, из них самые крупные вот-вот за 10 гиг перевалят

> Уже не у меня, но только одна из табличек в 3 раза больше. Под постгресом.

Это чисто чтоб попонтоваться или ты просто не заметил, что "10 гиг" - это не предельная величина, а просто приведены для сравнения с лицензионными ограничениями оракла? И при чем, спрашивается, тут постгрес?

> Уже не у меня, но только одна из табличек в 3 раза больше. Под постгресом.

Значит, тебе "бесплатный" оракл тоже уже не светит.

А в табличке что? Данные с датчиков? Или BLOB'ы с картинками? А то в файербердовской конфе тут с месяц назад была ругань - товарищ тестировал блобы, пихал в них фильмы в DivX, и шо то там ему медленно показалось ;-)

Grue

>Redo - ne tolkko ydoben (ob etom vishe) no polezzen dlya Skorosti...

Kred, разве мы говорили про скорость? Это хороший способ вести полемику "база ненадёжна! - нет, надёжна, вот почему! - а зато она к диску постоянно обращается!".

Я сам видел тестирование реальной базы портированной с FB на Postgres. И да, с помощью журналирования массовые вставки/изменения отрывались от FB процентов на 50, а кое-где даже больше. Но это было, во-первых, давно (FB 1.0.3 против Postgres не помню какой), во-вторых, всё равно никаких тормозов не было ни там, ни там.

Меня коробит от поливания грязью любого продукта. Раз вас так цепляют щепки в глазу FB, значит, в своём глазу полено?

WildSery

> Собственно откуда возьмутся незарегистрированные накладные или деньги 
> пропадут, если только девелопер не накосячил с управлением 
> транзакцией? После падения база (если только хард не помер) будет в 
> состоянии последней зафиксированной транзакции. Или вам журнал 
поможет
> что-то сверх этого восстановить? Незакомиченные изменения? ;)

Достали. Я уже писал. Запрос к базе исполняется, прога показывает что,
все ок, печатает накладную, ты ее подписываешь, отдаешь чуваку и он уезжает. А теперь летит винт.Или питание пропадает в компе. Ты 
поднимаешь базу ЗА ВЧЕРА. Где этой накладной, и еще 50 штук нету. И ты 
начинаешь мучительно вспоминать
кому и что выписывал на какий суммы и какие товары. Даже если все это 
есть - его надо вбить в базу заново. А у тебя обращения к базе с 
приемом товара подписываются смарт-картой того чувака, который уехал
 - вместе с документом ложится salt и хеш. Ну вот и привет. 
Отчеты полетели. Смену ты не закроешь.Короче привед. В лучшем случае 
будеш долго и мучительно накладные восстанавливать. 
Или, что еще хуже, ты че-то продавал. И никаких накладных нет.
А тока гора чеков. Штук так 1000. В каждом по 10 товаров. )))

> Значит, тебе "бесплатный" оракл тоже уже не светит. Я знаю. Бесплатный db2 с органичением на два физических камня тоже, ибо на четырёх оптеронах скрипит на пределе.

> А в табличке что? Данные с датчиков? Или BLOB'ы с картинками?

Тот самый онлайн биллинг, с претензией на серьёзность, за час простоя которого товарищи свыше надолго портят настроение.

> А то в файербердовской конфе тут с месяц назад была ругань - товарищ тестировал блобы, пихал в них фильмы в DivX, и шо то там ему медленно показалось ;-)

Честно говоря, я бы на месте владельца потратил бы $160k на оракл, проект явно постгресс перерос. Для задач поменьше - отличная база, а так, допустим, явно прозрачных репликации и работы в кластере не хватает.

> Это чисто чтоб попонтоваться или ты просто не заметил, что "10 гиг" -

Да, пиписька у тебя короткая, я бы постеснялся вот так, при людях.

Это ты попонтоваться вылез со своими 10 гигами (у нас памяти на сервере больше) Данных может быть 10 мегабайт, но за их исчезновение или недоступность в течении двух минут dba прилюдно проведут процедуру кастрации.

> это не предельная величина, а просто приведены для сравнения с лицензионными ограничениями оракла? И при чем, спрашивается, тут постгрес?

Есть бесплатные поделки любительского уровня, есть бесплатные академические поделки. А есть платные поделки (да, они тоже глючат), при использовании которых ты платишь з/п оглоедам в саппорте, чтобы они тебе доказывали, что чёрное - это белое. Если сил и ума хватает самому проявлять инициативу - пожалуйста, флаг в руки. Как надоедает, всё чаще приходят мысли о раскручивании работодателя на платное решение.

> Для задач поменьше - отличная база, а так, допустим, явно прозрачных репликации и работы в кластере не хватает.

В предверии вопросов про "репликацию и кластер": готовую, тяжелонагруженную постгресовую базу с кучей триггеров на slony переводить осмелиться только самоубийца или диверсант.

>А теперь летит винт.Или питание пропадает в компе.

ну тут еще можно выкрутится райдом или ихним shadow, проблема вылезет когда глючит райд или винда в результате во все зеркала пишется мусор, а при востановлении хотя бы на вчера выясняется что gbak немного глюкнул и бэкап невостановимый :) вот тогда и приходит понимание, что такое продукт, а что такое грязь.

Minotauros.

> Это ты попонтоваться вылез со своими 10 гигами

Дурик! Я никуда не вылазил, исходный пост не мой, а это мое второе письмо тебе. А может и не тебе, т.к. ты такой же анонимус, как и я и как и автор поста про 10-гиговую базу. И он не "вылез попонтоваться" как ты, а привел реальные цифры, на которых лицензия не позволила бы использовать бесплатный оракл. Из каких эротических соображений ты тут приплел свои супертаблички на постгресе - я ХЗ, но они тут совершенно не в тему. Так что можешь радоваться своей немеряной крутости и дальше - мешать не буду. :) :) :) :) :)

> выясняется что gbak немного глюкнул и бэкап невостановимый :) вот тогда и приходит понимание, что такое продукт, а что такое грязь.

Не, оно приходит когда скрипт от pg_dump'а сутки накатываетя на базу, а через неделю выясняется, что часть данных в нее по какой-то неведомой причине не попала. И что теперь процедуру восстановления предстоит повторить заново.

> Так что можешь радоваться своей немеряной крутости и дальше - мешать не буду. :) :) :) :) :)

Отойди, пенис положить мешаешь

> Не, оно приходит когда скрипт от pg_dump'а сутки накатываетя на базу,

Интереса ради, а дамп в plain text?

Minotauros, что за упорное мнение, что бэкап базы в FB является средством для её восстановления в случае сбоя?

И вообще, ты работал с FB? У тебя были невосстановимые бэкапы? Если были - то это только от твоих кривых рук. У меня в скриптах написано тестовое восстановление бэкапа на другой сервер (для проверки). Невосстановимый бэкап бывает раз в полгода (на 30 с чем-то базах в регионах, точно не помню - надо считать), и он не мешает по указанной причине.

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

> Это ты попонтоваться вылез со своими 10 гигами

Это не он, это я вылез. Просто пример реальной, без напряга работающей на FB системы.

> приходят мысли о раскручивании работодателя на платное решение

Будешь смеяться. Платное решение - оно может быть как раз на firebird. Даже не "может", а есть. Вот как раз то, с "базами на 10 гиг" ;-)

Grue

>Minotauros, что за упорное мнение, что бэкап базы в FB является средством для её восстановления в случае сбоя?

вообще я считаю это еще и единственым средством в ФБ :)

>Грязь - это то, что ты пишешь.

согласен, а что я говорю неправду ? искажаю факты ? может утрирую ?
ты сам понимаешь, что все так и есть и никаких перспектив. Что же касается грязи, а кто ж как ни ФБ еще заслуживает грязи: невостановимый бэкап, отсутсвие лога, глючащий SQL это НЕДОСТАТКИ !? БД с недостками круче я заню только фокспро ...

Minotauros.

Начет бэкапа: Бэкапить можно и сторонними утилитами. Да и вообще вероятность такого очень низка - за 1,5 года у меня ни одного. Лог... хз никогда не требовался мне и на постгресе (к слову сказать я с постгреса перешёл на FB). Обычно если БД летит, то окончательно и наглухо. Что у меня не случалось ниразу - другим помогал у кого было. Хреново значит сам сервак сконфигурировали. UPS + зеркалирование, если данные настолько важны. Тогда просто средствами операционки обойтись можно.

SQL? Я пока не видел ни одной СУБД на столько приближенной к стандарту SQL92. Не делай кривых запросов и всё. Любой запрос можно сформировать несколькими способами. Не одного глюка в его работе не заметил.

В самом крайнем случае при похереной наглухо БД - Hex-редактор (WinHex, например) в руки и вперед. В одной закладке бэкап, в другой похереная БД. У меня редко уходило больше 2-х часов на восстановление похереной БД, пока работал бэкап. Потом восстанновленные записи заливаем в работающий бэкап и всё. Почти всё можно восстановить на любой СУБД ручками, кроме конечно того, что в кэше было. А если нужна надежность, то пожалуйста жертвуйте скоростью и уменьшайте кэш, чтобы меньше потеря была, зеркалируйте, делайте частые бэкапы.

Да, есть у FB некоторые неудобства, но ничуть не больше чем в постгресе и большинстве других СУБД - всё имеет недостатки. Мне вообще удобней FB. Для разных нужд нужно использовать разные СУБД - универсального ничего не существует (иначе получится MS Office). Каждая имеет что-то своё. И задача хорошего разработчика ПО и БД не обосрать какую-то определенную СУБД, а выбрать наиболее хорошо подходящую в его конкретном случае. Нельзя тупо ограничиваться одной СУБД для всех своих проектов! Я, например, делал проекты на DBase, Paradox, Acces, FoxPro, PostgreSQL, FB, IB, Oracle, MySQL, SYBASE, MS_SQL и др. И все они хорошо работают в той области и для того объёма данных, для которых я и их делал. Это не моё мнение, а мнение админов, которые админят эти системы. Их работы там минимум.

Ребята кончайте сравнивать - начинайте работать. Что прямо как дети. Запомните: нет ничего универсального - всё подбирается под конкретные нужды. Плохой разработчик системы выберет не "плохую" СУБД, а "неподходящую" в данном случае.

>Если у тебя онлайн биллинг, не терпящий минутного простоя - firebird не для тебя. Вот в этом ты не прав, как раз у меня задачи которые идут ДО билинга, и ни че FB пашет. >Ищи что-то, поддерживающее FailOver clustering. http://www.ibase.ru/ibinstall/ib7cluster.htm

> Ребята кончайте сравнивать - начинайте работать. Что прямо как дети.

Разве думать можно только детям?

Курить про Shadow DB.

Думать надо, а не спорить ни о чём :) Вроде как ветка предназначена для обсуждения нового релиза FB, а не спора о том какая СУБД лучше.

Давайте сравним еще легковую машину, грузовик, трактор и мотоцикл :). Для разных вещей нужна разная функциональность. Можно конечно всё делать на чём-то одном, но ей богу это глупо :)). Представляете, как везти пару тон груза на мотоцикле или легковушке? А как быстро добраться по городу на грузовике?

Разные цели - разные средства. А СУБД это лишь средсво для достижения работы клиент-серверной системы. Какая ситема, такое и средство.

Так же сопорить что лучше - Вынь и Линух. Для разного они предназначены и глупо их сравнивать.