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

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

Flat | Top-Level Comments Only

Дальнейший разговор с вами считаю бессмысленной тратой времени.

А в нем смысла с самого начала не было, - упертый деревенский дельфист, кроме fb ничего не видевший, - дескать, какой смысл в новых технологиях, что такое standby..

Совсем разные рыночные ниши. Всякая торговля, учет и бухгалтерия на мелких-средних конторах запросто закрывается наколенными решениями на FB, оракл они по деньгам не потянут, а postgresql банально не моден в разработке под виндами, из-за того, что появился там в нормальном виде заметно позже FB/IB.
Бывает вплоть до того, что даже денег на нормальное железо не выделяется - "зачем, если оно и так работает". Это такой специальный вид жадных клиентов :)

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

Не-не-не, одинэсники как раз ходят и требуют правильного железа.
Что бы один - по терминал-сервер (ибо обычным клиентом оно до сих пор хреново работает) второй - сервер приложений, третий - сервер БД.
И это при том что работает на этом всем пяток бухов а исходные данные получают из моей программы которая крутится на обычном писюке и с ней работают порядка 30 юзеров одновременно.

Была мысль кстати заюзать для 1с8 вместо MS SQL - postgres ваш, ибо одинэсы сделали такую возможность. Оказалось что постгрес сам по себе ничего не решает, несмотря ни па партицирование ни на прочие плюшки. одиэс не может с ним нормально работать. только с MS SQL.

Три сервера для пяти бухов - что вы здесь видите правильного?

одиэс не может с ним нормально работать. только с MS SQL.

Это говорит только об унылости первого.

>> Это говорит только об унылости первого.

Дак я и согласен. И требования одинэса к железу из этого же и проистекает.
И весь такой крутой и благостный PostgreSQL тут ничем помочь не может, сколько бы у него настроек не было.

По секрету скажу, что 1с и с ораклом работает. И там даже RAC возможно использовать.
Только всё это очень и очень криво.
Постгрес - используется пропатченная криворукая версия. Вроде работает, а вроде и не совсем. Я бы от 1с вообще чудес не ожидал в любом случае.

"Что бы один - по терминал-сервер (ибо обычным клиентом оно до сих пор хреново работает) второй - сервер приложений, третий - сервер БД.
И это при том что работает на этом всем пяток бухов"
- восьмерка нормально работает и в режиме файлового сервера на одном довольно средненьком сервере, - это уж своему админу (если таковой имеется) лучи поноса посылайте.

Патчи там касаемо кодировок и сортировок, ничего принципиального вроде не меняли.
1с с ораклом работает вероятно так же как и с Firebird - ручным творчеством.
Об оригинальном решении от одинэса по работе с ораклом я не слышал.
Если бы оно было - то скорее всего они бы и с постгрессом связыватся не стали послали бы просто на XE.

В режиме файлового сервера оно работает как все файловые серверы. Т.е. падеж базы более вероятен. И такой режим на восьмерке с нагрузкой больше минимальной обычно не юзают.

По поводу криворукости - там оно везде. "Программист одинэс" и "программист" - совершенно разные профессии.

> Патчи там касаемо кодировок и сортировок
- касаемо блокировок транзакций. Хотя для кого-то - что сортировки, что блокировки - все одно. Пустой звук.
> Об оригинальном решении от одинэса по работе с ораклом я не слышал.
- на офсайте поищите, оно там есть довольно давно уже.

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

> "Программист одинэс" и "программист" - совершенно разные профессии.
- "программисты на дельфях" не сильно далеко ушли.

С блокировками как раз все плохо.
Желтая программа умеет работать только с блокировочниками.
MS SQL умеет блокировать построчно.
Postgre построчно не умеет, получается только страницами. Из-за этого в одинэсе прут конфликты блокировок.
В одинэсе пытались реализовать какой-то альтернативный вариант реализации блокировок - но у них тоже не получилось.

Программисты на дельфях как бы более в курсах что там унутре происходит и чего надо оптимизировать. А питонисты как ко всему этому относятся? :)

> Программисты на дельфях как бы более в курсах что там унутре происходит и чего надо оптимизировать.
- что - "унутре"? не, мне правда интересно, - Вы что под "унутре" подразумеваете? Использование win API? Давно напрямую окошечки и кнопочки создавали? Сокеты использовали?

> Postgre построчно не умеет, получается только страницами.
- no comments. Вы специально петросяна тут пинаете?

ну надо же вас потроллить как-то :)

..другого-то не умеете ..)

А что, надо в совершенстве уметь срать на софт с каким не работал? Так это у вас лучше получается, к чему в вами с этом состязаться.

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

(no subject)

fraks-nsk.livejournal.com - 2011-04-13 09:39 (UTC) - Expand

(no subject)

sgalitsky.livejournal.com - 2011-04-13 09:44 (UTC) - Expand

WinAPI не юзаю, окошки вручную не создаю, сокеты напрямую тоже не трогаю. Как бы незачем это все :)
А вот как клиентский датасет ускорить путем отказа от него - это да :)
Ну и собственно работа с базой и разработка этой базы. Оптимизировать можно не только крутя настройки у сервера :) но и правильно раскладывая данные по таблицам, запросы и процедуры. А зачем вам это все?

- акуеть какие умения и знания "унутре".
ну да один товарищ Вам тут диагноз сразу поставил. пока он подтверждается чуть более, чем на сто процентов.

Этот один товарисч идет прямым ходом нахуй.

Вот тута подробненько вся эта ситуация Pg + 1с описана.
http://www.gilev.ru/1c/81/postgresql/

Да, с блокировками одинэс решил у себя ничего не трогать а ковыряться в Pg.

Короче один фиг - работать нормально невозможно.

А про работу 1с с ораклом - откуда такая инфа?

во-первых, Вы можете зайти на официальный сайт 1с. я об этом писал, но Вы ж букварь еле осилили.. http://v8.1c.ru/overview/Term_000000135.htm
во-вторых, если это действительно так интересно - пройти официальный курс администрирования oracle для 1с. кстати, г-на Гилева я там видел среди слушателей.

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

Оракл идет нафиг. Если я правильно понял то ограничения XE нам не подходят. А покупать оракла для 1с нет никакого смысла. Проще купить MS SQL на который оно и заточено.

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

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

SAP не нужен, даже даром.

Сквозное решение на 1с нормальным вариантом у нас не считается ибо имеет совершенно неправильные требования к железу и софту. И возню с лицензиями - и на TSE и на 1с и на MS SQL. Тем более что одно и то же самописное решение у нас применяется и в филиалах. В случае одинэса пришлось бы покупать все это и туда.

Это вопрос не отсутствия денег а в отсутствии смысла использовать решения которые еще потом требуют платы за лицензии. Ибо и в случае с 1с все равно получается самописка.

все стоит денег. даже 1с.
винда и офис стоят денег.
серверы стоят денег.
- какая новость..