[mifi]

Цитата:

Сообщение от Recoilme

Попробую обосновать (честно говоря сужу по описанию САПа, как там на практике - не знаю).
1. Например, столкнулся с ситуацией описаной здесь:
Управление опциями SQL запроса
когда аксапта ко ВСЕМ запросам добавляет неотключаемый хинт оптионфаст приводящий к полному ауту в отдельных случаях.

Насколько я понял в САПЕ это регулирует разработчик

2. &REPARSE&
Сталкивался с ситуациями когда по непонятным причинам в одном и том же запросе то строился правильный план - то не строился, подозреваю что этот хинт мне бы помог так как юзался старый план.
3. SAP_FORCE_CLOSE_CURSOR, OPTION FAE_UNION и OPTION FAE_JOIN
точно не знаю, но возможно тоже могли бы пригодится.

Огромная просьба, расскажите если не сложно, как это можно на х++ реализовать,

Минусы (на мой взгляд, если не так - просвятите плз):

4. Честно говоря я думал в САПе сцылочная целкостность, тригеры хранимки на уровне БД, а теперь такое ощущение что нет? пора разочароваться?

5. Вроде как в дждиэдвардс только так(4), получается , из известных?

6. Инфо-предприятие - рулез форева, поскольку выходит только в нем?!?!? я могу написать ПЛАН(ывалыдвллвыа) и непариться вообще?

ой, не заметил:

Думаю это плюс. В разных СУБД разный оптимизатор, где то хинты навредят, где то помогут, в общем случае

Давайте по пунктам.
1. Эта функциональность Аксапты описывается как один из основных принципов оптимизации в вашей ссылке №1 (Выбирайте только необходимые записи) По поводу намеку оптимизатору - я не понял, почему вы называете это "намеком", из текста статьи следует, что это именно указание использовать данный индекс (вариант того, что такого индекса нет, не рассматриваем), т.е. поведение аналогичное index hint в X++.
2. Практически подобного же поведения можно добиться, используя ключевое слово forceLiterals - тогда, чтобы оптимизатор БД взял старый план, запрос должен быть тем же самым с точности до значений полей.
3. IMHO, детали реализации ABAP.