Перепост, про 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
no subject
no subject
no subject
Неужели это вы? ;)
no subject
no subject
А фраза про гугл звучала так многозначительно :)
no subject
как по мне - ничего особеного.
no subject
И таки программинг - питон, php и веб-технологии.
У FB несколько другой наклон, хотя конечно не исключает и такого.
no subject
это ж АВТОМАТИЗИРОВАНИЕ на firebird розничной и ОПТОВОЙ торговли. базы на несколько гигабайт.
свят-свят-свят..
no subject
no subject
Каким образом я могу однозначно связать ник с тем что выдает гугл?
Лучше гитарой побренчите, это вероятно у вас лучше выходит.
no subject
no subject
>Лучше гитарой побренчите, это вероятно у вас лучше выходит.
- не вижу, как это связано с темой. лучше чем-то что выходит? связно можете излагать?
no subject
no subject
no subject
Бывает вплоть до того, что даже денег на нормальное железо не выделяется - "зачем, если оно и так работает". Это такой специальный вид жадных клиентов :)
no subject
no subject
Что бы один - по терминал-сервер (ибо обычным клиентом оно до сих пор хреново работает) второй - сервер приложений, третий - сервер БД.
И это при том что работает на этом всем пяток бухов а исходные данные получают из моей программы которая крутится на обычном писюке и с ней работают порядка 30 юзеров одновременно.
Была мысль кстати заюзать для 1с8 вместо MS SQL - postgres ваш, ибо одинэсы сделали такую возможность. Оказалось что постгрес сам по себе ничего не решает, несмотря ни па партицирование ни на прочие плюшки. одиэс не может с ним нормально работать. только с MS SQL.
no subject
Это говорит только об унылости первого.
no subject
Дак я и согласен. И требования одинэса к железу из этого же и проистекает.
И весь такой крутой и благостный PostgreSQL тут ничем помочь не может, сколько бы у него настроек не было.
no subject
Только всё это очень и очень криво.
Постгрес - используется пропатченная криворукая версия. Вроде работает, а вроде и не совсем. Я бы от 1с вообще чудес не ожидал в любом случае.
"Что бы один - по терминал-сервер (ибо обычным клиентом оно до сих пор хреново работает) второй - сервер приложений, третий - сервер БД.
И это при том что работает на этом всем пяток бухов"
- восьмерка нормально работает и в режиме файлового сервера на одном довольно средненьком сервере, - это уж своему админу (если таковой имеется) лучи поноса посылайте.
no subject
1с с ораклом работает вероятно так же как и с Firebird - ручным творчеством.
Об оригинальном решении от одинэса по работе с ораклом я не слышал.
Если бы оно было - то скорее всего они бы и с постгрессом связыватся не стали послали бы просто на XE.
В режиме файлового сервера оно работает как все файловые серверы. Т.е. падеж базы более вероятен. И такой режим на восьмерке с нагрузкой больше минимальной обычно не юзают.
По поводу криворукости - там оно везде. "Программист одинэс" и "программист" - совершенно разные профессии.
no subject
- касаемо блокировок транзакций. Хотя для кого-то - что сортировки, что блокировки - все одно. Пустой звук.
> Об оригинальном решении от одинэса по работе с ораклом я не слышал.
- на офсайте поищите, оно там есть довольно давно уже.
> И такой режим на восьмерке с нагрузкой больше минимальной обычно не юзают.
- пять пользователей - это небольшая нагрузка.
> "Программист одинэс" и "программист" - совершенно разные профессии.
- "программисты на дельфях" не сильно далеко ушли.
no subject
Желтая программа умеет работать только с блокировочниками.
MS SQL умеет блокировать построчно.
Postgre построчно не умеет, получается только страницами. Из-за этого в одинэсе прут конфликты блокировок.
В одинэсе пытались реализовать какой-то альтернативный вариант реализации блокировок - но у них тоже не получилось.
Программисты на дельфях как бы более в курсах что там унутре происходит и чего надо оптимизировать. А питонисты как ко всему этому относятся? :)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)