Перепост, про 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

[metaclass.livejournal.com]

Не, настоящий standby это совсем не то. В идеальном случае, пользователи вообще не замечают, что что-то изменилось. Но это стоит столько, что окупает себя только в особо злых случаях.

[fraks-nsk.livejournal.com]

дык я понимаю что и стоит недешево и для того что бы он работал нормально, или хотя бы что бы просто работал - и админы нужны соответственные. Только к чему тут товарисч [info]sgalitsky такие бочки скатывает?
У меня все больше впечатление что он не программер а некий админ прыг-прыг по конторам, сам толком ничего не написал поэтому и вопрос представляет весьма поверхностно.
Базы на которые он ссылается - писал не он и сопровождал по всей видимости тоже не он. Его дело - микро-скриптики на питоне которые ХЗ что делают.

[metaclass.livejournal.com]

Firebird удобен для программистов и неудобен для админов. Поэтому он в основном занимает нишу "софт, который пишется и обслуживается одними и теми же людьми". Админы же как-то неодобрительно к нему относятся.

[fraks-nsk.livejournal.com]

Потому что там крутить особо нечего, да и без знания потрохов - непонятно что.
У меня вообще все там по дефлоту стоит, ничего не кручу :)
Максимум - отключу неудачный индекс по +0 и стараюсь меньше использовать inner join ибо он дает больше воли оптимизатору.
Планы не прописываю.

[metaclass.livejournal.com]

Ну, я тоже не кручу, кроме кэшей и физического расположения баз.
А вот насчет "меньше использовать inner join" - это еще что за вуду новое такое?:) Я его постоянно использую, там где по логике положено.

[fraks-nsk.livejournal.com]

Лично мне больше понятен outer join. Где нужен именно inner - конечно пишу inner.
Но если без разницы - то всегда напишу outer. И в большинстве случаев обычно outer и обхожусь.

тривиальный случай

шапка документа
left join ссылки на справочники из шапки
left join тело документа
left join справочник товаров
left join ссылки из справочника товаров на другие справочники

Ну или движение
select
from тела документов
left join шапки документов
left join справочники из шапки документов

where код товара = :код товара

[metaclass.livejournal.com]

Эээ, в случае шапки left join имеет смысл только если нет внешнего ключа, или поле в шапке может быть null.
Т.е. "можно ввести товар, которого нет в справочнике" или "можно не вводить товар вообще".

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

[fraks-nsk.livejournal.com]

>> то надо inner join.

Не "надо" а "можно". А можно и не использовать.
Если сделать inner - то не исключено что начнет джойнить от справочника а не от шапок.

[metaclass.livejournal.com]

Да, интересное вуду. Я думал, что inner join заведомо эффективнее.

[fraks-nsk.livejournal.com]

Оно может и эффективнее если
- ты правильно выбрал inner
- мозги оптимизатора круче твоих

[fraks-nsk.livejournal.com]

С inner - там ведь оптимизатор сам определяет с какой таблицы начинать. Иногда может начать не с той. Причем это может случиться не сразу а по мере заполнения таблицы. Мне же лучше обычно видно где можно изначально больше отрезать и не лопатить миллионы и какая таблица "большая" - сейчас или будет впоследствии.

[metaclass.livejournal.com]

А это общеизвестная шиза и лечится пересчетом статистики по индексам, через некоторое время после заполнения основной таблицы.
Оптимизатору мерещится, что лучше будет выбрать короткую таблицу, а дальше долбится в длинную по FK.

[fraks-nsk.livejournal.com]

Вот именно из-за изменения статистики шиза может посетить не сразу а через некоторое время, в продакшене.
Что бы превентивно избежать - я и использую left. Ну и кроме того - тупо понятнее как он работает. Возьми слева вот по этим условиям а потом к тому что получилось прицепи вот это, по таким признакам. Никакой неоднозначности.
В случае inner - слепи A и B да так что бы и слева было и справа было.
И если каким-то образом справа чего-то не хватило - то и слева чего-т оне увидишь.
Каюсь, был грех - справочники без FK. :) Там это особенно актуально.

[w00dy.livejournal.com]

мне кажется что в случае если программист и жнец и на дуде игрец, то как-то пофиг на чём писать, главное чтобы удобно себе любимому было. Просто FB, как мне кажется, пишется программистами для программистов для простых инфраструктурных сценариев, вот удобство отсюда и растёт. И лично я, из своего опыта, не сказал бы что тот же mssql мне поддерживать сложно.