IT-redneck

Не вижу ничего позорного, если имеете доказательства, прошу предоставить. Усвою и поблагодарю. А опыт у меня ровно обратный.

Дмитрий, ваша роль в околоинтербейзовом комьюнити должна, по идее, быть аналогична Тому Кайту. (Том Кайт - это такой ИИ, который завелся внутри оракла от переизбытка кода и поэтому всё о нем знает )

А вы паясничаете, по сути.

Что вы хотите мне доказать мелкими придирками? Что IB быстр, документирован, надежен и беспроблемен в эксплуатации? Вы до сих пор впариваете доверчивым людям эту чушь?

Да я специально этот тред завел только ради того, чтобы поделиться своим опытом с IB/Firebird. И я верю, что плохие решения должны умирать, а хорошие - жить. Надеюсь кто-нибудь прочитает это, и НЕ КУПИТ решение на базе IB. Вероятность низка, но тем не менее.

Ещё раз, не отвлекаясь, повторяем мантру все вместе: Interbase/Firebird - это некачественное, плоходокументированное, медленное, проблемное в эксплуатации семейство серверов.

From:

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

С медленностью вопрос неясный. На данный момент у меня три варианта медленной работы: 1) устаревшая статистика индексов. Лечится однократным ее обновлением. 2) Загадочное поведение на некоторых виндовых серверах (на линуксах не пробовал, не знаю) - тупо работает в 5 раз медленнее чем на аналогичных машинах. В чем причина - то ли SATA контроллеру стиль работы не нравится, то ли диск сдыхает, то ли в FB что-то не то - не знаю. 3) Мой личный плющ - где то остается не завершенная транзакция и начинает расти разрыв между oldest snapshot и текущей транзакцией, из-за чего перестает собираться мусор и начинает тупить. При моих сотнях транзакций в секунду это быстро складывает сервер.
Я не знаю, что в таких случаях делают другие версионники - не пробовал.

From:

Про SATA не знаю, а вот на вот на некоторых SCSI-контроллерах такая фигня была. Причем не на всех. У себя - всё нормально, а у заказчика прям было слышно по звуку как контроллер всё в пакеты раз в секунду отдавал.

From:

>тупо работает в 5 раз медленнее чем на аналогичных машинах.
включите Write Cache у контроллера диска. Выучите наконец эту область администрирования железа, освойте perfmon, что-ли.

From:

Там траблы с чтением были.
Кстати, эта птица не на всех контроллерах включается, драйвера не дают вроде

From:

в драйверах SCSI это практически нигде не включается. Для raid контроллеров кроме драйверов нужно обязательно ставить программу управления этим контроллером. Потому что параметры контроллера управляются, как правило, только таким образом, по крайней мере под Windows.
Почему этот софт не ставят поставщики компов и админы-самосборщики - загадка.

Админы обычно скачут с бубном вокруг таких систем, лезут в биос, дрова, и естественно, ничего не находят. Правда, с добыванием софта, управляющего конкретным RAID, бывает цирк - в ноябре в одной конторе сутки не могли скачать его с hp.com. И что более загадочно, на диске с дровами этого софта тоже не было.

From:

>Не вижу ничего позорного, если имеете доказательства, прошу предоставить.
Позорно то, что Вы не задумываясь транслируете чужие заблуждения. Если бы Вы задали вопрос, я бы ответил. Но Вы стали УТВЕРЖДАТЬ что план запросов вкомпилирован в процедуры.

Тем не менее, опровержение повторяемого Вами заблуждения найти очень даже можно:
1. берете любую базу IB/FB с процедурой, в которой есть запрос.
2. открываете базу в IBExpert.
3. select * from rdb$procedures
4. в записи с нужной Вам процедурой есть столбец rdb$procedure_blr. Тыкаете в его содержимое. Это блоб.
5. переключаетесь в закладку as BLR.

Я хотел было привести сюда пример примитивной процедуры, но форматированный blr занимает много места. приведу отдельно.

>Что вы хотите мне доказать мелкими придирками?
почему мелкими? Вы несете чушь, и более того, сомневаюсь что только в этом месте.

>Что IB быстр, документирован, надежен и беспроблемен в эксплуатации?
да, все перечисленное, и именно у IB все хорошо с документацией. Вот у FB - плохо.

>чтобы поделиться своим опытом с IB/Firebird.
нет у Вас никакого опыта. Мало того что Вы откуда-то чужие слухи начинаете транслировать, так еще и "опыт" этот имели 11 лет назад. Да, InterBase 5.6 на текущий момент - полное говно, по сравнению с IB 2007/2009 или последними версиями Firebird. А 11 лет назад был вполне ничего.

>Ещё раз, не отвлекаясь, повторяем мантру все вместе
К чему эти злобствования, которые совершенно не соответствуют действительности?
Вы как эмигрант, уехавший из СССР до 1991 года - все коммунисты за углами мерещатся.

From:

Придирки мелкие потому, что вы выбираете утаревшие или несущественные утверждения. Оспорьте существенные: скорость, рестор из бакапа.
Причем, заметьте, я заранее даю вам все карты в руки и признаю за вами больший и главное современный опыт. Нет же нужно развести гуманитарную клоунаду.

И не передергивайте на коммунистов, не выйдет.

Апеллируйте к основным факторам - скорости, стоимости эксплуаталии. Что, нечего сказать?

From:

А с чем вы сравниваете? Имею опыт сравнения с Ораклом. Firebird на небольших объемах уделывает Оракл (даже их бесплатную Express версию) по стоимости и простоте эксплуатации в разы. Точнее - даешь клиенту инсталлятор, который все у него сам устанавливает, ему даже не нужно иметь квалифицированного админа. Если у клиента проблема - он пакует базу и присылает ее тебе. Ты ее правишь и отправляешь ему обратно. И ни какой магии с консолью. А скорость нужна далеко не везде.

P.S. Но за все это приходится платить геморроем при разработке. Одно отсутствие Invalid object-ов обошлось там во многие человеко-дни. Но в постгресе их тоже нет.

From:

Invalid object - это что в виду имеется?

From:

Если добавляешь или удаляешь поле в таблице, от которой зависят вьюшки и хранимые процедуры, от которых в свою очередь зависят другие вьюшки и хранимые процедуры и т.п., то в Firebird-е приходится сначала удалять все зависимые объекты, изменять таблицу, а потом создавать все зависимые объекты заново. В Oracle вместо этого зависимые объекты помечаются признаком "Invalid" (не всегда, обычно, если после изменения объекта их невозможно скомпилировать, например, если удалили поле, на которое реально была ссылка во вьюшке). Их можно перекомпилировать, и они снова станут валидными. Благодаря этому внесение изменений в базу резко упрощается. У нас софтина сама обучена при необходимости вносить изменения в схему БД, поэтому для Firebird пришлось ее учить пересоздавать все дерево зависимостей.

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

From:

А, с зависимостями это мрак, да. Сложновато переделывать бывает.

А вот эксклюзивного доступа вроде и в FB не требуется - главное чтобы объект изменяемый сейчас не трогал никто.

From:

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

From:

А что происходит если не выгнать?
Я помню несколько вариантов:
1) в какой-то версии просто не давало менять занятые SP и ругалось сообщением. Сейчас просто пишет в лог.
2) сейчас если менять объект, прямо сейчас используемый в незавершенной транзакции - вроде тоже ругается
3) на классике не сразу обновляется кэш метаданных, во всяком случае, другие процессы сразу изменения не видят (давно не перепроверял, может уже и исправили).

Вообще ключевой аспект, что достаточно делать транзакции короткими и всегда закрывать их (commit или rollback) - тогда никаких проблем нет.

From:

Сравниваю с ораклом и MSSQL.

Справедливости ради надо заметить, что процедура инсталляции у всех СУБД сейчас приблизительно одинаковая. Оракл сильно упростил инсталлятор. А MSSQL умудрился усложнить.

А там где скорость не нужна можно всё просто в XML положить или в sqlite.

From:

Справедливости ради надо заметить, что процедура инсталляции у всех СУБД сейчас приблизительно одинаковая

Сказки только не надо рассказывать. Для Firebird можно сделать свой собственный инсталлятор, который все установит, пропишет куда надо чистую базу и все сразу заработает. Для Oracle, если нет выделенного админа - приходится посылать пошаговые инструкции что и куда нажать надо, и все равно каждый раз какой-нибудь новый геморрой всплывает. Спасибо, плавали, знаем.

А там где скорость не нужна можно всё просто в XML положить или в sqlite.

XML - сразу видно большого специалиста. Скорость важна = миллионы и десятки миллионов записей. Скорость не важна - сотня тысяч записей и меньше. XML - это файлы конфигурации. Sqllite - не многопользовательская СУБД и не поддерживает вложенных SQL.

From:

А я и не рассказываю сказок. У оракла сейчас реально простой инсталлятор, можно отдать любому дауну - даун установит. Для MSSQL всегда можно было делать кастомные инсталляторы. Я делал. Но не с целью упростить, он там и так простой как валенок, а с целью развернуть ещё кое-какие свои пакеты сразу с инсталляцией сервера.

А про XML и Sqllite прошу прощения - совсем забыл что нужна многопользовательность.

From:

>А вы паясничаете, по сути.
сейчас выясним, кто паясничает. Предлагаю посмотреть процедуру и ее blr. И найти там вкомпилированный план запроса.

create PROCEDURE a
as
declare variable i integer;
begin
select emp_no from employee
where EMP_NO = 1
into :i;
end;

blr_version5,
blr_begin,
blr_message, 1, 1,0,
blr_short, 0,
blr_begin,
blr_declare, 0,0, blr_long, 0,
blr_assignment,
blr_null,
blr_variable, 0,0,
blr_stall,
blr_label, 0,
blr_begin,
blr_begin,
blr_for,
blr_singular,
blr_rse, 1,
blr_relation, 8, 'E','M','P','L','O','Y','E','E', 0,
blr_boolean,
blr_eql,
blr_field, 0, 6, 'E','M','P','_','N','O',
blr_literal, blr_long, 0, 1,0,0,0,
blr_end,
blr_begin,
blr_assignment,
blr_field, 0, 6, 'E','M','P','_','N','O',
blr_variable, 0,0,
blr_end,
blr_end,
blr_end,
blr_end,
blr_send, 1,
blr_begin,
blr_assignment,
blr_literal, blr_short, 0, 0,0,
blr_parameter, 1, 0,0,
blr_end,
blr_end,
blr_eoc

From:

форматирование убилось, к сожалению.

From:

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

Я не буду сейчас искать IB 4.0 или 4.2.

From:

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

>Я не буду сейчас искать IB 4.0 или 4.2.
чего искать-то. у меня на компе есть. Я как раз с 4.0 и увидел, что планов в процедурах нет. isql уже очень давно позволяет посмотреть blr процедур и триггеров.

From:

Признаю, в этом случае похоже я не прав.

From: