Перепост, про Firebird

[metaclass]

ссылка
В бане (или борделе, кто куда ходит), после грамотной попарки (или еще чего), распаренный партнер подсказывает генральному, что во всем виноват тормозной 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 чипсете, съеденными мышами проводами, на котором кишат вирусы, админов нет, а пользователи качают с китайских серверов зоофильское порно с троянами и червями".
Я до сих пор не могу забыть, как админы клиентов базу данных бухгалтерской системы один раз удалили вместе с образом виртуальной машины, а в следующий раз, уже после переселения на физическую машину, у них просто ВЫПАЛ ПРОВОД из винчестера во время работы. Слава богу, база была на другом винчестере.

Comments

[sgalitsky.livejournal.com]

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

у меня складывается впечатление, что напиши товарищ один раз промежуточный tier для sqlite, например, - и все были бы довольны все эти долгие 10 лет непоймичегоделанья.
..только о sqlite такие редкости обычно и не слышали, как и о присноупомянутом стэндбае.

[metaclass.livejournal.com]

nosql типа монгодб не рассматриваем, это ад и холокост, пусть его еще пять лет попилят.
sqlite же блокирует базу целиком на момент записи, хоть и работает в многопоточных приложениях. Кроме того, у него с типизацией полей печаль.

А, и да - firebird имеет embedded вариант - как раз та же ниша, что sqlite. И переход от embedded к нетворк - замена одной либы, из-за чего практикуется такое: показываем клиенту продукт, вообще его не инсталлируя, тупо скопировав в флешки, один пользователь пользуется, потом переселяем на сервер, когда захотят остальные пользователи и запинают свое начальство и ИТ-службу.

[sgalitsky.livejournal.com]

nosql мне лень сейчас осваивать. скорее всего, - зря.

да, у sqlite нет многоверсионности (лень в педивикию лезть, по-моему так называется по-русски), - и что?
- в "этой нише" ("в этой стране"..))) вполне сойдёт.
для баз 2-3 Гб и парой-другой тысяч пользователей - запросто, думаю. - А это - уже не ниша для fb, кстати. Оно там сдохнет неминуемо. А настраивать - нечего. И покупка "полки" - лишь отсрочит окончательное и неминуемое.

Я просто немного удивлен. - Как за десять лет человек с этим не сталкивался? Автоматизацию бань, прачечных-х*чечных налаживал?

[metaclass.livejournal.com]

Не, MVCC это отдельная история.
sqlite и nosql конкретно мне не нравятся тем, что нет принуждения со стороны СУБД использовать правильные структуры данных - в sqlite можно записать строку в числовое поле и никто не почешется, а в nosql вообще структура(вроде бы) определяется клиентским приложением, и разработка чего-то более-менее осмысленного гарантированно закончится собственной реализацией sql/транзакций и прочего поверх nosql баз.

Ну я с требованием standby и прочего подобного тоже не сталкивался ни разу. Все просто: клиенты до сих пор работают с прогой на кларионе под DOS и файл-серверные БД. По сравнению с этим софт на Firebird - это уже небо и земля.

[sgalitsky.livejournal.com]

а что, - для нормального ПО это характерно? - ссылаться на ошибки СУБД?

[metaclass.livejournal.com]

Для нормального ПО характерно использовать СУБД и язык по максимуму, не изобретая велосипеды.
В частности, внешние и прочие ключи используются как последний эшелон защиты от ошибок. Т.е. пользователю клиентское ПО, конечно, не дает ничего плохого сделать, показывая осмысленные сообщения, но ограничения в БД делают это дело более надежным.

[sgalitsky.livejournal.com]

> Ну я с требованием standby и прочего подобного тоже не сталкивался ни разу.
- я примерно понял, о чем Вы говорите.
- не проще ли тот же постгре освоить? он-то ведь и настройками побаловать может, и позволяет на пару-другую Гб/Тб базу раздуть. - да, вполне..

[metaclass.livejournal.com]

Да, с постгресом имеются планы на будущее.

[sgalitsky.livejournal.com]

Проще прямо сейчас. - фб пара лет осталось. - либо сами загнутся, либо кто-нибудь купит.
то же самое и с постгресом случится, - то же самое, что и с MySQL.
а у постгреса есть многое от оракла. после него на оракл (и db2?) переходить проще..

[fraks-nsk.livejournal.com]

> для баз 2-3 Гб и парой-другой тысяч пользователей - запросто, думаю. - А это - уже не ниша для fb,
> кстати. Оно там сдохнет неминуемо.

С чего бы. У вас я вижу охуенный опыт работы с Firebird?

> Я просто немного удивлен. - Как за десять лет человек с этим не сталкивался? Автоматизацию бань,
> прачечных-х*чечных налаживал?

Оптовая и розничная торговля. Регион от Новосибирска до Иркутска.

В центральном офисе максимальное кол-во коннектов к базе - порядка 30 наверное.
Соответственно все ваши рассуждения про тысячи коннектов и тербатайтные базы - для меня пустой звон. У меня этого не и не будет.

[sgalitsky.livejournal.com]

>> прачечных-х*чечных налаживал?
>Оптовая и розничная торговля.
- да понял, понял. не переживайте так.

[fraks-nsk.livejournal.com]

Прокольчик.
2-3 гига и 2-3 тысячи пользователей - это что-то странное.
Вы цифры с потолка берете, по аналогии с веб-сайтами с которым наверное и имеете дело...
Нишу эту FB покрывает нормально, но что могут делать 2 тысячи пользователей с такой небольшой базой...

У меня менее 30 пользователей набивают 1,5 гига за 1,5 года.

[sgalitsky.livejournal.com]

> Кроме того, у него с типизацией полей печаль.
- с какой стороны посмотреть. я его давно не юзал. последний раз - под тиклем, - что в тикле - каждая переменная - строка, что в sqlite (а он из тикля и вырос) - то же самое.

под питоном поюзал слегка - для внутренних нужд, - переменные и файлики хранить, - какие проблемы с типизацией?

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

[metaclass.livejournal.com]

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

[sgalitsky.livejournal.com]

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

[metaclass.livejournal.com]

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

Ну и клиентских софтин может быть много разных, вплоть до доступа к БД из систем других производителей, лучше пусть БД от особо деструктивных действий охраняет.

[sgalitsky.livejournal.com]

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

[vp.livejournal.com]

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

[sgalitsky.livejournal.com]

не знал от этого проблем, кстати. наоборот, - весьма удобно, без привязки к типам.
а насчет даты-времени - так вот оно - чего искать-то? http://www.sqlite.org/lang_datefunc.html

[vp.livejournal.com]

Ну это называется "стоя в гамаке" :)

[sgalitsky.livejournal.com]

это называется "не баг, но - фича"..)
- одну функцию написать для времени/даты - много ли надо..

[fraks-nsk.livejournal.com]

> весьма удобно, без привязки к типам.

Это писец. офигенный программер :)
Вы походу кроме своего питона ничего освоить не смогли :)

[sgalitsky.livejournal.com]

я где-то себя программером обозвал?

[sgalitsky.livejournal.com]

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

[fraks-nsk.livejournal.com]

Во времена выбора IB этого sqlite наверное еще и в помине не было.
А FB весьма неплохо развививается, не требует никаких дописываний лично мной и покрывает все мои задачи.
Зачем мне скакать с сервера на сервер следуя текущей моде если есть нормальное решение, не хуже других и ничего уже переделывать ради просто переделывания - не надо?