Timur AkhmadeevAlexander Ryndinпропущено...
просто начальник олдскульный попался. Раньше в оракл не было join, а когда появились иногда глючили. Сейчас это уже мало актуально
Настолько "мало", что упоминается в свежем документе :
The only way to execute such a query was to translate it into ANSI syntax. However, the implementation of such ANSI syntax results in a lateral view6 being used. Oracle is unable to merge a lateral view, so the optimizer’s plan choices are limited in terms of join order and join method, which may result in a sub-optimal plan.
Багов ANSI пофиксили в:
11.2.0.2: 22
11.2.0.3: 14
11.2.0.4: 26
12.1.0.2: 141. Во-первых от версии к версии уменьшается число случаев когда ansi конвертируется в lateral view (которая non mergeable). То, что раньше порождало lateral, сейчас может генерировать inline view или без view вообще.
2. Во-вторых "another was to execute such a query" это вручную переписать через inline view.
3. В-тетьих непонятно почему выбрано именно это ограничение, более того, если уж сравнивать то имеет смысл последнюю версию, либо делать оговорки про изменения. С таким же успехом можно было выбрать, что предикат внешнего соединения до 12с не мог содержать скаляров.
4. Native syntax имеет баги и на 12с, и чо?
Timur AkhmadeevДед, слушайся начальника, исключение - full outer join.Тебе не мешало бы хорошенько подтянуть матчасть.

GlaysДед-Папыхтет, тру ораклоиды используют NATURAL JOIN и USING.Тру ораклоиды пишут на смеси синтаксисов, чтоб ни нашим не вашим.
И у ребятишек с категоричностью высказываний рвало шаблон. :)

Если же дело касается внутренних соединений, то все таблицы можно перечислить через cross join, а предикаты запихнуть в where.
Любители native syntax и свалки предикатов в where должны оценить.

Vintfull outer join - это ошибка архитектуры которую надо исправлять на ранних стадиях. потом будет больнее.Тебе не надоело как попугаю повторять свои заблуждения. Перечитай еще разок 19249657 .
Для полноты картины, в OLTP full join может понадобиться разве что для отчетности, в хранилищах и для отчетности, и для ETL и для прочего.
Это не отменяет того факта, что такие вещи как full join или distinct часто говнокодеры используют не по назначению.

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

AlexFF__|К чему это все?Cлегка раздражает безапелляционный тон.
AlexFF__|Ты как будто отговариваешь людей покупать иностранные машины и приобретать жигули.Можно подробнее объяснить аналогию?
Говоря про возможности, ansi позволяет достичь всего того, что позволяет native и даже более, но не наоборот.
С появлением lateral/outer apply в 12с границы еще более стерты.
Единственное в чем ANSI уступает - в возможностях хинтований. Порождаемые ansi/lateral views делают хинты невалидными.

Как-то Сергей Арсеньев тут заявил, что "ансишный синтаксис это синтаксический сахар". С этим можно согласиться.
Тогда и аналогию можно провести ansi vs native как c vs assembler.
И далее, приходит некто и категорично заявляет, что Си использовать не стоит поскольку предыдущие версии компиляторов криво транслировали в исполняемый код.

Vintdbms_photoshop,
твои примеры как раз и являются для меня исключениями подтверждающими правило. но специально для тебя напишу что full outer join в 99% случаях используется неверно. теперь с категоричностью полегчало? или дальше копья будем ломать?)
ну хочешь я еще могу написать что model так же как match recognize желательно не использовать вообще. Такие конструкции можешь использовать ты, и люди очень глубоко разбирающиеся в архитектуре люди, но 99% разработчиков оракл даже не знают про преобразования full outer join, lateral преобразования или микрооткаты merge. поэтому такая категоричность имхо вполне допустима для людей которые задают вопросы. потому что если ты дошел до уровня когда не хочется задавать вопросов - ответы ты найдешь и сам. и советчики тебе при этом не особо нужны)Я соглашусь, что model и recursive subquery factoring желательно не использовать вообще.
Вызывали некоторое недоумение некоторые последние статьи Кайта где он писал про "прекрасные решения на model/rec with". Видимо ему действительно пора было на пенсию.
Удивляет когда на этом форуме SY публикует какие-то решения на rec with когда решается c помощью connect by и прочие overkill.
Забавно что тот же SY и прочие продолжают навязывать агрегацию строк через XML, которая есть костыль с хреновым перфомансом.

Вообще в оракловом компьюнити многие люди, которые имеют некоторый вес продолжают пиаирть какие-то говно подходы. И тех, кто адекватно может оценить просто мизерный процент. Кстати, зачаствую они и на форумах не сидят. Так что любезный товарищ "бурлесонщина" из другого топика частично прав: общий уровень низкий, процент тупости растет и говно-решения упорно продвигаются.
А умные люди развивают свое дело, занимаются семьей, спортом, туризмом... чем угодно. А не пасутся в коментариях к блогам Подера и Льюиса.
Это, конечно, не повод всех назывть "лохи позорные" или как там было.

В вот match recognize - ВЕЩЬ! Я обо всем этом написал 100+ страниц, скоро выложу.

Timur Akhmadeevкоторые поясняют, почему я не люблю ANSI синтаксисМожно еще раз разжевать плиз.
А то в примере вроде как про ограничение native а ты не любишь ansi.
Я правильно понял, что нелюбовь связана с тем что ansi может порождать lateral?

У тебя в профиле почта рабочая? Могу скинуть аргументацию в деталях. Но там много букв. Хоть я и старался структурировать получше.

Glays,

Ну это еще по доброму.
Я как-то лет 10 назад работал в одной не софтварной конторе, в которой программистов было меньше чем пальцев на руках и у всех были админские привилегии в локальной сети.
Когда я уже уволился - пришел новый чел, который не особо нравился некоторым и они периодически ребутили его комп удаленно по локальной сети командой shutdown с указанием веселых сообщений, таймаута и флага force.
Пока не вытравили беднягу.

RA\/ENdbms_photoshopЯ соглашусь, что model и recursive subquery factoring желательно не использовать вообще.
Вызывали некоторое недоумение некоторые последние статьи Кайта где он писал про "прекрасные решения на model/rec with". Видимо ему действительно пора было на пенсию.
Удивляет когда на этом форуме SY публикует какие-то решения на rec with когда решается c помощью connect by и прочие overkill.
Забавно что тот же SY и прочие продолжают навязывать агрегацию строк через XML, которая есть костыль с хреновым перфомансом.

Вообще в оракловом компьюнити многие люди, которые имеют некоторый вес продолжают пиаирть какие-то говно подходы. И тех, кто адекватно может оценить просто мизерный процент. Кстати, зачаствую они и на форумах не сидят. Так что любезный товарищ "бурлесонщина" из другого топика частично прав: общий уровень низкий, процент тупости растет и говно-решения упорно продвигаются.
А умные люди развивают свое дело, занимаются семьей, спортом, туризмом... чем угодно. А не пасутся в коментариях к блогам Подера и Льюиса.
Это, конечно, не повод всех назывть "лохи позорные" или как там было.

В вот match recognize - ВЕЩЬ! Я обо всем этом написал 100+ страниц, скоро выложу.
Коллега, вы просто разрыв шаблона вызываете. Model использую давно (редко, да метко). Никаких проблем.
А вот на match recognize с первого раза вляпался в баг, локализовывал который целый день.
Но при этом Вы заявляете, что model (со времен 10.2?) - кака, а match recognize (свистоперделка из 12.1) - ми-ми-ми и повод для 100-страничного эпоса. Не странно ли?В эпосе намного больше страниц посвящено модели чем паттерн матчингу, не смотря на озвучиваемую мной ее бесполезность.
Я был бы премного благодарен, если вам есть что сказать по поводу этого challenge .
По поводу альтернативных случаев не очень интересно - например, когда на наборе, скажем, 50к строк можно натянуть модельку и вся логика умещается в пару строк, тогда как на PL/SQL пришлось бы создавать функцию, тип и писать много букв, а перфоманс сопоставимый ибо объемы детские.

andreymxиквалайзерпропущено...


Например, когда требуется вычислить разницу в хранящихся данных (одна условная таблица/набор) и тех же данных, получаемых "на лету" (другая условная таблица/набор). Не думаю, что это архи-редкость..матёрому старперу для этого достаточно пары-тройки юнионовЛюбители нетрадицинных подходов вполне могут реализовать full join и без ansi и без union.