softwarerВо-первых, pipelined - это просто вариант табличной функции (полагаю, именно она подразумевалась под возвратом коллекций).
Если я правильно Вас понял, то Вы неправильно меня поняли (о как выкрутил!) :)

PIPELINED - это один подход;
Возврат коллекции, созданной как SQL-тип в БД и в которую в результате обработки помещены данные - это другой подход;
Под коллекцией я понимаю SQL-тип вида CREATE TYPE xxx IS TABLE OF yyy;

Под SYS_REFCURSOR я старался подчеркнуть использование нестрогой ссылки на курсор, т.к. есть код, который в зависимости от входных параметров возвращает разные результаты. Подход с REF CURSOR RETURN не используем, вместо него используются либо PIPELINED, либо коллекции.

softwarerСоответственно, там, где есть такой стандарт, практически всегда выбирается что-то одно, как минимум в рамках приложения.

Полностью с Вами согласен. Но кто сказал, что разработчик БД поддерживает только 1 приложение? В мою сферу работы входят как динозавры, написанные во времена Oracle 8, и успешно работающие до сих пор, так и приложения, использующие последние фишки Oracle 11 (например, приложение 24*7 c применением Edition-Based Redifinition).

Поэтому разработчик БД кодирует в тех стандартах и применяет те подходы, которые были приняты в свое время для конкретного приложения. Этим же стандартам следует и разработчик приложения.

softwarerВ конце концов, проще принять стандарт типа "данные всегда возвращаются через ref cursor; если нужна табличная функция, она возвращается через refcursor-обёртку"
Стандарт принять может быть и проще, а вот менять существующий, успешно и надежно работающий и приносящий прибыль код ради "чистоты стандартов" - слегка неверно, я считаю. Ведь в этом случае код нужно: поменять, протестировать, задеплоить. А это время и деньги тех людей, которые будут вовлечены в такие изменения. В нашей компании изменения в стиле "давайте сейчас все перепишем заново" делаются только в крайних случаях, когда мы упираемся в существенные ограничения в рамках выбранного подхода. А это всегда Epic Fail и прощелк на предыдущих этапах разработки, хотя иногда и случается...

vadiminfoНу, к примеру, как разрешается конфликт юзеров? Ведь теперь нет всяких там рекордсетов или там датасетов, которые поддерживаают сами оптимистическую блокировку
Мы стараемся не использовать программные продукты, которые САМИ чего-то там поддерживают и представляют из себя черный ящик, непонятно как работающий.

Есть подход с использованием оптимистической блокировки. Есть подход с использованием пессимистической блокировки. Есть подход вообще без блокировки. В зависимости от потребностей используется один из вариантов, осмысленно используется.

vadiminfoчто говорить о тереотическом обосновании, что является более оптимальным все еще преждевременно.
Согласен, мы вообще не можем говорить об оптимальности или неоптимальности ЛЮБОГО подхода, не рассматривая окружение и условия, в которых этот подход применяется.

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