iBase.ru Forum

При переводе базы с IB 7.5.1 на FB 2.1. столкнулся с такой проблемой.
В IB из-за его любви пересекать индексы а потом самому же от этого и пухнуть во многих местах приходилось явно указывать планы. В результате появилось много запросов вида:

select from table1
left join table2 ...
....
plan (table1 index tbl1_idx)

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

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

Но вот с планами проблема. Убрать их нельзя - IB будет тормозить. Дописать полные в большинстве случаев нельзя - джойны в основном по PK идут, с указанием индексов для которых как известно в IB большая проблема.

Таким образом получается, что ведение проекта параллельно и без дополнительных затрат на IB и FB в данном случае - утопия?

А что, на IB даже +0 не спасает?

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

Поэтому и интересует - можно ли как-то обойтись малой кровью?
Ну или планируется ли что-то подобное в ближайших версиях FB.

с указанием индексов для которых как известно в IB большая проблема.

позволю вам не позволить... оптимизатор, ясное дело в IB хуже чем в FB, но тем не менее не настолько крив чтобы ВСЕМ запросам надо было планы гвоздями прибивать.

Ну если бы всем, то сейчас наверное вопрос о миграции в свете этой проблемы вообще бы не стоял

Но многим - это да. Они все однотипные - есть 2-3 боооольших таблицы, которые являются основой для почти всей аналитики. А аналитика - больше 100 отдельных отчетов, у каждого своя хранимая процедура (или несколько). Хотя большинство обращений к этим большим таблицам - однотипные, с вариациями. И когда базы подросли и стали очевидны приколы с пересечениями индексов тонко разбираться не стали понаставили планов везде, практически копи-пастом, да и все. Наверное тогда перегнули палку, по-быстрому хотели. Впрочем до сих пор это никаким боком не выходило.

В общем никто ж не говорит, что IB или FB - кривые, а разработчики - ангелы безупречные. Но вот так сложилось, а теперь хочется это разрулить. Опять же по-быстрому

заставить fb воспринимать такие планы - нереально.

Мы вот базу к FB2 полгода готовили.
Поспешишь - граблей огребёшь, как говорится.

У нас думаю в итоге где-то столько же выйдет..
Собственно проблема не в переводе, а в желании иметь еще и такую же рабочую на ИБ и вести ее параллельно (на уровне метаданных). Желание это собственно из опасения, что наступим на какие-нить непреодолимые грабли в FB и придется срочно откатываться обратно. Грабли в ИБ все такие родные уже, а тут - почти полная неизвестность, страшно

Ладно, видимо ничего лучше последовательного пересмотра всех планов и их убиения/замены на "+0" тут и правда не придумаешь

Спасибо всем откликнувшимся.