Перепост, про 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
И таки программинг - питон, 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
- что - "унутре"? не, мне правда интересно, - Вы что под "унутре" подразумеваете? Использование win API? Давно напрямую окошечки и кнопочки создавали? Сокеты использовали?
> Postgre построчно не умеет, получается только страницами.
- no comments. Вы специально петросяна тут пинаете?
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
http://www.gilev.ru/1c/81/postgresql/
Да, с блокировками одинэс решил у себя ничего не трогать а ковыряться в Pg.
Короче один фиг - работать нормально невозможно.
А про работу 1с с ораклом - откуда такая инфа?
no subject
во-вторых, если это действительно так интересно - пройти официальный курс администрирования oracle для 1с. кстати, г-на Гилева я там видел среди слушателей.
по поводу блокировок - перечитайте гилевский текст пару раз. может быть, что в голове появится. но я в этом очень не уверен.
(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)