![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Перепост, про Firebird
ссылка
В бане (или борделе, кто куда ходит), после грамотной попарки (или еще чего), распаренный партнер подсказывает генральному, что во всем виноват тормозной 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)
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? А, ну идите в топку, пионеры из НИИГиТ.".
Ребе
theiced вообще убеждает меня, что базы Firebird регулярно отправляются на марс, со всеми данными :) И таки да, надо признать, такое бывало, меньше 1% случаев, но бывало. Я не знаю, как обстоят с таким дела у всяких Ораклов или PostgreSQL, но меньше 1% излечимых отказов, при жестоко удолбищных условиях эксплуатации - это имхо, вполне хорошо. Возможно, я чего-то не понимаю, и отказов вообще быть не должно.Если посмотреть на среднего вопрощающего на sql.ru или на отвечающих ему местных "гуру", то причины такой ситуации становятся более понятны - вопрощающий обычно реально пионер из НИИГиТ, отвечающие или модераторы - несдержанные на язык красноглазики, в самом лучшем случае - делающие гешефт на Firebird и около того товарищи.
И еще один аспект - это те самые условия эксплуатации. Oracle/MSSQL - это значит заведомо нормальный сервер, инфраструктура и наличие обслуживающих админов. PostgreSQL/MySQL - наличие в дельта-окрестности следящего за инфраструктурой красноглазика.
Для Firebird же типичная инфраструктура - "первый попавшийся десктоп с виндой, с матерью на nvidia чипсете, съеденными мышами проводами, на котором кишат вирусы, админов нет, а пользователи качают с китайских серверов зоофильское порно с троянами и червями".
Я до сих пор не могу забыть, как админы клиентов базу данных бухгалтерской системы один раз удалили вместе с образом виртуальной машины, а в следующий раз, уже после переселения на физическую машину, у них просто ВЫПАЛ ПРОВОД из винчестера во время работы. Слава богу, база была на другом винчестере.
no subject
деньги разные.
задачи разные.
серверы разные.
не доходит?
no subject
no subject
когда Вам нечего сказать, Вы повторяться начинаете.
ему говорят, что до хуя больших контор, которые и оракл и сан покупают. - нет, йопт, в моей деревне таких не имеется.
говорят, что кроме устаревшего барахла, есть бесплатные, стабильно развивающиеся СУБД, - нет, йопт, мне старое нравится, нового я не понимаю, оно вообще никому не нужно.
а потом про - "начало доходить". дубово, чо.
no subject
FB - нифига не устаревший а нормально развивающийся сервер с коммунити по всему миру.
Вот была такая контора, в нашем бизнесе и регионе - Топ-Книга. Увлеклась "решениями для больших мальчиков" - и кризис эту контору смертельно подкосил. У них там и SAP был и консультанты заморские, и один эс и самописки. Дохера чего крутого. И железо конечно. Но это не показатель эффективности.
А на нашу контору кризис не повлиял вообще, а на фоне гибели ближайшего и сильнейшего конкурента - так и вообще получили дополнительную долю рынка.
Вам пофиг на эффективность бизнеса - вам крутые железки и софтинки трогать нравится.
no subject
- мне нравится не железки и софтинки трогать, а когда мощное железо работает на полную. И когда бизнес не сидит в ебенях и сервером за 70 тыр хвалится.
Мне нравится то, что на бесплатном софте я могу организовать кластер. То, что это решение масштабируемо. Этому софту до оракла или db2 далеко. - Но у него больше возможностей, чем у фб. Вам эти возможности - глубоко параллельны. Вы научились кнопки нажимать в определенной последовательности, Вам этого хватает. Но про сообщество по всему миру, - не надо, да?
на hh.ru посмотрите -
77 вакансий за месяц - для фб, 43 для иб.
postgresql - 273.
oracle - 1983.
Это насчет востребованности и распространенности. Меньше сообщество, - дольше развивается, меньше возможностей. И вот эти бэкап-ресторы, отсутствие HA, кластеров, стэндбаев - прекрасное доказательство этой простой мысли.
Да, другая ниша. Но зачем отрицать очевидное, - реально мало возможностей. Вам может быть и хватает, но старье от этого новее не будет. Туда же и дельфи эти для любителей переписки в духе - "а какой вам компонент больше нравится для отображения даты/времени/дензнаков?".
no subject
Это вам как наемному администратору интересно.
А владельцу бизнеса интересно эффективно и просто решить задачу минимальными средствами. Все остальное - беллетристика. Бизнес и на FB сможет сидеть не в ебенях а в полном шоколаде - вопрос в том что за бизнес и какими средствами и подходами он автоматизирован.
>> Но про сообщество по всему миру, - не надо, да?
Посмотрите вот тут
http://firebirdsql.org/index.php?op=ffoundation&id=members
416 членов Firebird Foundation - это только те кто либо лично участвует в развитии или оплачивает участие других. Там и страны указаны, почитайте. А собственно разработчиков - в сотни и тысячи раз больше. А точек эксплуатации - естественно еще больше.
"Мало возможностей" вопрос не в количестве а в достаточности для задачи.
По вакансиям - не в курсе по каким критериям искали, но допустим если по администрированию - то для FB как правило тупо не нужен администратор, поэтому вакансий меньше.
По поводу ораклоидов - интересная ветка на
http://www.sql.ru/forum/actualthread.aspx?tid=843525
qwertyuiop107 > Нужно создать таблицу с 1300 колонками. Помогите. знаю есть ограничение на 1000 столбцов
env > Какую задачу вы пытаетесь решить?
qwertyuiop107 > я пытаюсь создать таблицу с 1300 колонками
no subject
416 членов. ну да. порадовали. сотни-тысячи разработчиков? и что они делают - х** пинают?
искал очень просто, там все вакансии с упоминанием той или иной субд.
> По поводу ораклоидов - интересная ветка на
- один дебил у других дебилов хуйню спрашивает. очень интересно..
no subject
Это не разработчиков FB это разработчиков софта с применением FB.
Не пинают, работают.
no subject
no subject
Я так понимаю за МКАД-ом жизни нет :)
> на hh.ru посмотрите
Зачем туда смотреть если человек продаёт готовое решение, а не работу ищет? Да и вообще, эта фалометрия по кол-ву вакансий не говорит ровным счётом ничего.
no subject
- это самый простой и быстрый способ оценить кол-во пользователей.
Впрочем, мне на Ваше мнение..
no subject