Перепост, про Firebird
ссылка
В бане (или борделе, кто куда ходит), после грамотной попарки (или еще чего), распаренный партнер подсказывает генральному, что во всем виноват тормозной Firebird, и надо переходить на "промышленные" СУБД.
...
Правильно затюнигованный Firebird держит 1500 активных клиентских подключений, обслуживает 400Гб базу, и экономит предприятию как минимум от $6000 за каждый процессор.
У меня на почве Firebird когнитивный диссонанс в крайней стадии.
Во-первых, он у меня работает в количестве нескольких сотен штук у разных клиентов. Во-вторых, я на его использовании съел собаку. В третьих, у меня кодогенератор пока заточен строго под Firebird и свои модели хранит тоже в Firebird. То бишь мне по долгу службы положено всюду Firebird пропагандировать и пиарить.
Но периодически возникают срачи с разного рода админами, коллегами-программистами и прочими причастными к теме, и все они крайне не любят оный Firebird. Типа истории про неуловимый баг "если в процессе работы почитать(скопировать) базу извне сервера, то база сдохнет. Оригинал сдохнет, не копия". Ну и прочие urban legends. У людей без мозгов вообще первая реакция примерно такая: "Firebird? А, ну идите в топку, пионеры из НИИГиТ.".
Ребе
theiced вообще убеждает меня, что базы Firebird регулярно отправляются на марс, со всеми данными :) И таки да, надо признать, такое бывало, меньше 1% случаев, но бывало. Я не знаю, как обстоят с таким дела у всяких Ораклов или PostgreSQL, но меньше 1% излечимых отказов, при жестоко удолбищных условиях эксплуатации - это имхо, вполне хорошо. Возможно, я чего-то не понимаю, и отказов вообще быть не должно.
Если посмотреть на среднего вопрощающего на sql.ru или на отвечающих ему местных "гуру", то причины такой ситуации становятся более понятны - вопрощающий обычно реально пионер из НИИГиТ, отвечающие или модераторы - несдержанные на язык красноглазики, в самом лучшем случае - делающие гешефт на Firebird и около того товарищи.
И еще один аспект - это те самые условия эксплуатации. Oracle/MSSQL - это значит заведомо нормальный сервер, инфраструктура и наличие обслуживающих админов. PostgreSQL/MySQL - наличие в дельта-окрестности следящего за инфраструктурой красноглазика.
Для Firebird же типичная инфраструктура - "первый попавшийся десктоп с виндой, с матерью на nvidia чипсете, съеденными мышами проводами, на котором кишат вирусы, админов нет, а пользователи качают с китайских серверов зоофильское порно с троянами и червями".
Я до сих пор не могу забыть, как админы клиентов базу данных бухгалтерской системы один раз удалили вместе с образом виртуальной машины, а в следующий раз, уже после переселения на физическую машину, у них просто ВЫПАЛ ПРОВОД из винчестера во время работы. Слава богу, база была на другом винчестере.
В бане (или борделе, кто куда ходит), после грамотной попарки (или еще чего), распаренный партнер подсказывает генральному, что во всем виноват тормозной Firebird, и надо переходить на "промышленные" СУБД.
...
Правильно затюнигованный Firebird держит 1500 активных клиентских подключений, обслуживает 400Гб базу, и экономит предприятию как минимум от $6000 за каждый процессор.
У меня на почве Firebird когнитивный диссонанс в крайней стадии.
Во-первых, он у меня работает в количестве нескольких сотен штук у разных клиентов. Во-вторых, я на его использовании съел собаку. В третьих, у меня кодогенератор пока заточен строго под Firebird и свои модели хранит тоже в Firebird. То бишь мне по долгу службы положено всюду Firebird пропагандировать и пиарить.
Но периодически возникают срачи с разного рода админами, коллегами-программистами и прочими причастными к теме, и все они крайне не любят оный Firebird. Типа истории про неуловимый баг "если в процессе работы почитать(скопировать) базу извне сервера, то база сдохнет. Оригинал сдохнет, не копия". Ну и прочие urban legends. У людей без мозгов вообще первая реакция примерно такая: "Firebird? А, ну идите в топку, пионеры из НИИГиТ.".
Ребе
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
Если посмотреть на среднего вопрощающего на sql.ru или на отвечающих ему местных "гуру", то причины такой ситуации становятся более понятны - вопрощающий обычно реально пионер из НИИГиТ, отвечающие или модераторы - несдержанные на язык красноглазики, в самом лучшем случае - делающие гешефт на Firebird и около того товарищи.
И еще один аспект - это те самые условия эксплуатации. Oracle/MSSQL - это значит заведомо нормальный сервер, инфраструктура и наличие обслуживающих админов. PostgreSQL/MySQL - наличие в дельта-окрестности следящего за инфраструктурой красноглазика.
Для Firebird же типичная инфраструктура - "первый попавшийся десктоп с виндой, с матерью на nvidia чипсете, съеденными мышами проводами, на котором кишат вирусы, админов нет, а пользователи качают с китайских серверов зоофильское порно с троянами и червями".
Я до сих пор не могу забыть, как админы клиентов базу данных бухгалтерской системы один раз удалили вместе с образом виртуальной машины, а в следующий раз, уже после переселения на физическую машину, у них просто ВЫПАЛ ПРОВОД из винчестера во время работы. Слава богу, база была на другом винчестере.
no subject
no subject
Если со второго delphi начинали, то лет десять с БД работаете. А толку - чуть.
no subject
Вы сами тут про FB спрашиваете. Почему я не могу спрашивать про что-то еще?
no subject
за 10 лет плотной работы с БД не знать, что такое стэндбай.. - или может быть, Вы его какими-то своими терминами обзываете? что, в общем, тоже характеризует.
no subject
no subject
- простота программирования
- простота деплоя
- простота администрирования
а из минусов:
- рано или поздно настанет полный пц с последующей миграцией, изменением кода, а скорее всего - и идеологии.
три плюса против одного минуса.. - слушайте, а ведь замечательное ПО!..)
no subject
>> - рано или поздно настанет полный пц с последующей миграцией, изменением кода, а скорее всего - и
>> идеологии.
Вы принимаете за истину постулат что все базы растут бесконечно, и из этого неверного постулата делаете вывод о непригодности сервера к бесконечному росту базы.
На самом деле бОльшая часть баз растет весьма ограниченно. И пипец не наступает.
В моем к примеру случае базы 0,5-2,5 гига. И даже если она вдруг вырастет в 10 раз - то никакой пипец не наступает. И даже если в 100 раз. Так что ваши страхи преувеличены. Слишком высоко летаете.
no subject
- меня бани, прачечные, оптовики и прочие коробейники давно не интересуют. Обсуждалась изначально оптимизация fb некой фирмой. Для случая, когда размер базы 400 Гб.
Вы слегка смахиваете на маньяка, который преследует других и постоянно нашептывает "у меня базы несколько гигов". И что дальше? Вас поздравить с чем-то или орден сутулого выдать?
no subject
База в 400гигов для FB - тут может оказаться над чем подумать, если не подумали при разработке.
Есть люди которые умеют это делать.
FB с такими объемами умеет справляться.
Вы начали это как-то опровергать.
Я всего-лишь попытался развеить ваше заблуждение.
no subject
no subject
no subject
Было бы конечно круто все это знать и считаться хорошим программистом, если бы жизнь была бесконечной, как и молодость.
Но между "быть крутым программистом" и "хорошо (эффективно) делать свое дело" нет знака равенства даже если мы говорим только о программировании.
no subject
На писях сначала пришлось столкнуться с чужой программкой на FoxPro 2.5.
Потом провали заказать себе программу на Клиппере, но программеры проебали исходники и отказались дальше что-либо делать. Пришлось брать дело в свои руки. С тех пор и держу. И вполне успешно. Метаться с платформы на платформу мне совершенно не с руки. Благо в свое время удачно выбрал IB - и собственно на нем/на его потомке до сих пор успешно и работаем, в куче филиалов в том числе.