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


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

RA\/ENdbms_photoshopВ эпосе намного больше страниц посвящено модели чем паттерн матчингу, не смотря на озвучиваемую мной ее бесполезность. А можно поглядеть уже?Можно если написать в почту в профиле.
RA\/ENdbms_photoshopЯ был бы премного благодарен, если вам есть что сказать по поводу этого challenge .
По поводу альтернативных случаев не очень интересно - например, когда на наборе, скажем, 50к строк можно натянуть модельку и вся логика умещается в пару строк, тогда как на PL/SQL пришлось бы создавать функцию, тип и писать много букв, а перфоманс сопоставимый ибо объемы детские.
Challenge сильно загадочный - очевидно, что для любого алгоритма, предусматривающего возможность двунаправленной навигации по датасету, можно разработать более эффективное решение на императивном PLSQL, чем на декларативном MODEL (это и самого SQL касается, в общем, если рассматривать его как фреймворк для задачи "прочитай мне с диска набор данных и сделай над ними group by"). Т.о. Вы предлагаете опровергнуть заведомо истинное утверждение.
Декларативный подход MODEL дает плюсы в том, что для его использования и отладки не надо иметь прав на создание объектов, т.е. их можно гонять на продуктиве, его быстрее разрабатывать и он понятнее широкому кругу лиц (по сравнению с PL/SQL).
Высокопроизводительный алгоритм на PL/SQL у меня навевает мысль о том, что кто-то влепил его не в то место, где он должен быть - масштабирование сложное, и ну очень дорогое. В сфере хранилищ проще оставить на базу подготовку датасета для обработки, а обработку - вынести на сервер приложений. В сфере OLTP алгоритм с MODEL на 1M+ строк вызывает подозрение в ограничениях проекта, ведущих к извращениям. Я когда-то Excel парсил в OLTP-базе на 8-ке, но это не потому, что извращениец, а потому, что ресурсов на промышленное решение на Delphi не было (а для предобработки изучил VBA).
Так что абстрактно сравнивать эти два подхода, в отрыве от конкретной задачи, не имеет смысла.Challenge предельно конкретный и точный, никакой абстрактности.
Ни о каких особенностях алгоритмов речь не идет, включая всякие двунаправленные навигации.
Цель проста: либо демонстрируется конкретный пример задачи с решением на model для 1М строк для которого нет аналога на PL/SQL быстрее либо нет.
Для всех прочих возможностей SQL таких как joins, connect by, analytic/aggregate functions, pattern matching и проч такой пример можно предоставить.
И тем более не надо усложнять еще более и обсуждать, что все можно выгрузить в память на серваке и там колдовать с наборами данных на C.
Или даже вспоминать серверы приложений. Речь про базовые возможности Оракла для работы с данными - SQL and PL/SQL.

PS. На самом деле я могу показать, что даже для самого примитивного примера serial модель начинает деградировать намного сильнее чем PL/SQL при увеличении объемов, а вот при использовании parallel + model partition by ситуация несколько лучше, но все равно модель уходит в лузеры после определенного рубежа.
В целом, думаю мы "on the same page", в эпосе все описано детальнее. Challenge используется для легкого троллинга.
На скуле и не на скуле я использую абсолютно разный стиль подачи информации. :))