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

[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
- мозги оптимизатора круче твоих