Parazit написал:
__Gennady написал(а):
FOR ALL ENTRIES не зло при правильном использовании, особенно если почитать вышеназванные ноты.
При интерпретации он превращается либо в UNION либо в IN() либо в OR(.. and...) OR(.. and...)
Ну вот вы сами и описали его недостатки, ибо данные конструкции плохо оптимизируются СУБД.
Я всего лишь утверждаю, что если есть возможность построить оптимизированный запрос (исключения я уже описывал много выше), то использование FOR ALL ENTRIES абсолютно не оправдано, т.к. это неоптимизируемое обращение к СУБД.
__Gennady написал(а):
3. COLLECT для обычных (не сортированных или хеш-таблиц).
Я надысь наткнулся, оказывается САПа уже оптимизировала COLLECT для несортированных таблиц, правда с оговорками, что модификация таблицы производится только через COLLECT. Подробности не помню, см. HELP.
1. Тот факт что запрос без for all entries лучше, чем с ним - слишком очевиден, чтобы его обсуждать.
Но иногда оказывается эффективнее разделить запрос на несколько.
Можно привести примеры, когда оптимизатор Oracle чудит, или промежуточная обработка оказывается более эффективной. Хороший вопрос что лучше - left outer join или дополнительный селект с for all entries? Хотя это уже не пример хорошо оптимизируемого запроса.
Я лишь хочу сказать, что for all entries неизбежность, да и в стандарте часто используется. Поэтому знать как это работает необходимо.
2. Да, про временный хеш-ключ я в курсе. Но по факту часто ловил чудовищно медленное выполнение collect, поэтому появился такой пункт в рекомендациях для команды разработчиков.
Вход
Регистрация
FAQ пользователя
Поиск
