особо с IB до сих пор я не работал, главным образом MSSQL
но вот понадобилось пристыковать к нашему (на MSSQL) чужой биллинг, а у него FireBird 1.5
ну естессно начал искать для IB аналоги MS EnterpriseManager и QueryAnalyzer
их отыскалось на удивление много
выбрал рекомендуемые IBASE.RU

1) SQLLY IBAdmin 4
2) EMS InterBase & FireBird Manager 3
3) HK-Software IBExpert v.2004.03.16
4) Marathon (open-source from sourceforge.net)

ну так вот
на обычных запросах по неиндексированной таблице в 54 поля и 30 записей
практически все они задумываются на заметное время, до 10 секунд

FB находится от меня на другом конце города, связь по выделенке 256к

при повторном запросе (не меняя его), Marathon (не смотря что интерфейсом похуже) начинает бегать заметно шустрее. Остальные как тормозили, так и тормозят.

Странно. Кстати тот же BDE-шный SQLExplorer показывает ту же скорость, что и "раздуплившийся" Marathon. Единственно, чем могу объяснить такие тормоза у остальных, так это перегруженностью различной статистикой и пр., сопровождающей каждый запрос.

НО ЧТО САМОЕ СМЕШНОЕ

Прилинковал я FB к MSSQL, стоящий на соседней с ним машине.
В качестве Linked Server'а. И делаю запрос к нему уже через MSSQL посредством консоли QueryAnalyzer.
И что? Догадайтесь с трех раз. Правильно, запрос выполняется едва ли не быстрее чем даже в BDE SQLExplorer.

Смешно да не до смеху.

Это что ж получается? "FB -> ODBC -> MSSQL -> ODBC->Клиент" выполняется быстрее, чем "FB->gds32.dll->FIB(IBO)" ??????

2 Dnico

Одна знакомая, которую муж застал с любовником, сказала так
"Не верь глазам своим, верь моему чистому сердцу" :)

Я же тоже не идиот, говорю о том, что есть. И не фантазирую. :)

Вот почему же MARATHON после первой попытки резко ускоряется?

Кеширование? Оптимизация?
Тогда почему остальные этого не делают?

Все тормозящие тулы заново препарят один и тот же запрос, в то время как Marathon и QueryAnalizer препарит его один раз и дальше только выполняет.

Но ведь QueryAnalyzer не тормозит даже на первой попытке запроса, в отличие от того же MARATHON'а
Или на это влияет то, что я через QA обращаюсь к MSSQL и основная работа по PREPARE происходит именно между машиной с MSSQL и машиной с FB, которые стоят в одной комнате.

что на медленных каналах определенно заметно.

Ну... выделенку 256к язык не поворачивается назвать "медленным каналом" :)

Чрезвычайная заумность тулов. Тот же IBExpert выполняет не то два, не то три лишних (т.е. отсебятина) запроса на каждый твой.

Мдааа... Признаться я тоже в первую очередь начал грешить на "заумность".
Причем мало того, что доп. запросы генерятся, когда не просишь, так еще, мне кажется, и вывод уже полученных данных притормаживает за счет необоснованно навороченного междумордия (пока эти все контролы с данными заново свяжешь, да затем обновишь на экране...) :)
По идее, все это должно быть настраиваемо.
НАРОД! Если кто будет писать подобные тулы, учтите. :)

проверил
запрос выполнился МГНОВЕННО

нет слов, одни междометия :)

с другой стороны, все же эти все тулы имеют много пользительных возможностей для ПРОЕКТИРОВАНИЯ БД
но вот оптимизировать с их помощью...

тот же QueryAnalyzer в MSSQL показывает план запроса только когда его об этом попросишь :)
что собсно есть нормально (IMHO)

т.е. по-хорошему тулза должна по умолчанию на запрос выдавать мне только его результат
а все остальное по желанию (т.е. если надо, включил опцию "А ЕЩЕ ХОЧУ ЭТО" и выполнил запрос повторно, уже для анализа)

IMHOIMHOIMHO :)

насчет индексирования системных таблиц
любопытно - это как? На мой непросвещенный взгляд это что-то типа "лезть туды куды следует". Или я не прав?

т.е. "куды НЕ следует"