Не ради холивара, но.
Есть таблица с данными, поля условно:
date, owner, object, ..... (other properties of owner and object)
Необходимо доставать данные в виде:


или в виде


Есть дублирующиеся данные и другие нюансы.
То есть надо доставать или объект и его владельцев с периодами, или объект и его владельцев.

Понятно, что запросы можно написать разные, но все они уложатся ну строк в 30, максимум 50 и будут выдавать сразу поля
Дата "С" Дата "По" и т.д. то есть практически готовый для выдачи результат. Но этот запрос будет содержать в себе подзапросы, функции группировки и возможно, аналитические ф-ции (можно и без них, но с ними короче и удобнее).
При этом запрос будет принимать на вход параметры для поиска или объекта или owner-а, т.е. один запрос-курсор с параметрами, а к нему будут обращаться разные функции для форматирования результата.
Плюсы подхода: лаконично, быстро, универсально при приемлемой производительности.
Минусы ( не с моей т.з.): "сложные" селекты сложно сопровождать и масштабировать (например, если возникнет необходимость добавить еще несколько таблиц, как источник данных, хотя на мой взгляд, это не проблема, - есть вьюшки, подзапросы)

А можно написать самый простой селект фром where (отдельно для каждого варианта поиска), все загнать в коллекцию, и потом уже формировать выходные данные путем ручной сортировки, группировки элементов коллекции в PL/SQL.
Плюсы ( не с моей т.з.): - простые селекты позволят легко добавлять данные из разных источников (вероятность такой необходимости есть примерно раз в год), т.е. будет единая функция группировки через коллекцию, в которую можно будет загонять данные из разных источников, т.е. масштабируемость
- легко сопровождаемый код
Минусы (по-моему): напротив код с коллекциями будет менее удобен сопровождении, чем небольшой селект на 30 строк

Есть еще средний вариант - временные таблицы (во всяк. случае сортировать и группировать данные в них было бы проще), но он как бы вообще не рассматривается по чем зря по-моему, с т.з. достижения компромисса почему бы нет.

Но за все время еще не встречал таких извращений, чтобы приходилось в коллекциях именно PL/SQL руками делать то, что можно сделать сразу в селекте (группировка, сортировка) :(. Кто что скажет.

Если короче, то:
Универсальный небольшой селект с подзапросами (ну да с не очень тривиальной сортировкой, ну да с нетривиальной группировкой, с отсечением дублей). Общий объем порядка 30 строчек.
vs
Простой селект фром where c запихиванием в коллекцию и дальнейшим разгребанием коллекции на предмет сортировки, группировки, чтобы получить на выходе данные как в первом варианте с селектом.
(основная мотивация - начальству не нужен селект, в котором будет разбираться только один человек (при этом считается, что код разгребания коллекции будет гораздо понятнее)) :(

andrey_anonymous, спасибо.
moishamiem, не могу оценить насколько хорошо с SQL, но что-то похожее вполне может быть.
пиcателНу если начальство ставит вопрос ребром, то, имхо, нужно сделать так, как требует начальство. :)
Сколько у него (у начальства) вообще человек, которые разбираются?
Народу, кто разбирается, хватает, вопрос в том, захочет ли кто-то вникать в селект чуть более сложный, чем просто селект фром where 90%, что ответ - "нет" (при этом никто у них не спрашивал, захотят ли они вникать в то же самое на PL/SQL). Плюс начальство по опыту сталкивалось с тем, что наращивали, наращивали селект под изменяющиеся данные и источники данных и в итоге он превратился в такой, что разбираться в нем стало категорически сложно. Поэтому в итоге все переписали по второму варианту. И с этим согласен и могу представить такую ситуацию и такой запрос. Но возможно, смотря как его строить. И новые источники появляются не часто и не много 1-2 в год-несколько лет.
Но да, в конечном итоге вопрос ребром походу...
Всем спасибо, на этом наверно все (для себя выяснил, что не одинок в своем видении)).