FuzzyЯ не собираюсь работать с Ораклом, к сожалению. Да и не хочу привязываться к какой-то определённой базе. Хочется универсального решения, шаблонного.

Чем тебе не шаблонное решение?


Объектный SQL скоро будет реализован во всех коммерческих СУБД, и твоё шаблонное решение уйдёт в небытие, как худше из всех возможных, поскольку в общем случае API БД никакой оптимизации в твоей задаче не допускает но тебе придётся ориентироваться на него.

FuzzyА щас всё-таки надо работать с API БД как есть.

А какой есть?

FuzzyТак что насчёт хранимок, как ими воспользоваться для решения моей задачи?

Откуда мне знать? Может твоя БД хранимые процедуры не поддерживат?

А вообще, с ХП всё точно так же, только SQL запросы храняться на стороне сервера. ХП возвращает массивы записей, которые нужно рассортировать по прикладным объектам.

FuzzySeVa, ну причём тут готовое решение? Хочется просто понять, сколько и каких СЕЛЕКТОВ будет выполнять сервер для того, чтобы выбрать на клиента коллекцию объектов, каждый из которых сам содержит коллекцию объектов.
Какие бы ни были там процедуры, SQL сервер всё равно ведь будет выполнять именно запросы.
И не получится ли, что запросов будет 1 плюс ещё по запросу на каждый "главный" объект для выборки соответствующих подчинённых?

В лучшем случае для множества объектов с одной вложеной коллекцией нужно выполнить 2 запроса. Один за множеством главных объектов, второй за вложенными коллекциями. В худшем 2x<количество выбираемых объектов>, хуже только по дури можно сделать. Фактическое количество запросов в данном случае зависит от возможностей API СУБД и твоего таланта.

Fuzzy...
3. Мчаться циклом по резалтсету главных объектов, для каждой записи:
а) создаём новый главный объект
б) мчимся циклом по резалтсету подчинённых объектов с текущей позиции, пока ключ бьёт с соответствующим главным объектом, создаём новые подчинённые объекты, пихаем в коллекцию.

Типа как-то так, видимо?

Типа того.

Пара замечаний.
1. В запрос подчинённых коллекций нет нужды тащить таблицу с главными объектами, если тебе известны их id, а они тебе известны, поскольку ты их выбрал первым запросом. Но в конкретном случае это может быть не важно. Если уж плясать в этом направлении, то можно одним запросом выбрать данные из таблиц с главными и подчинёнными объектами, правда размер выборки в байтах может ощутимо возрасти.
2. Твои циклы подразумевают, что строки в запросах будут предварительно отсортированы по id объекта. Это лишняя трата времени, не проще, но эффективенее сразу создать все главные объекты, а затем рассортировать по ним подчинённые записи, используя, например, хэш таблицу.

FuzzyНе совсем так, mcureenab, в запрос по подчинённым объектам я собираюсь передавать отнюдь не таблицу, а запрос по главным объектам. И по двум рекордсетам я буду бежать одновременно, и фетчить их тоже одновременно. Поэтому без сортировки по id не обойтись, конечно.

Дело твоё. Так тоже можно. Не факт, что будет производительнее, но определённо проще.

Хех. Я тут видал, программа за КАЖДЫМ атрибутом в БД обращалась. Обоснование было - канал медленный, и если нужен только конкретный атрибут, то тянуть весь объект будет накладно. Я сомневаюсь, но, полагаю, автор знал о чём говорит.

Сам делал объектный кэш на PL/SQL. Методы и SQL запросы генерились по шаблону автоматически для каждого класса объектов. Чтобы не усложнять шаблон и оставаться в его рамках, атрибуты объектов тянул только по id. Если требовался запрос не по id, то сначала выбирал список id, а потом типовыми методами подружал сами объекты по одному. Благо таких необъектных запросов было совсем чуть и претензий на всеобщность тоже не было.

FuzzySeVa, а я предпочитаю иметь на клиенте полноценный объект, а не полузагруженный.

Нуууу... Есть ещё ленивая инициализация и многие её успешно используют. Иногда запросу может пойти на пользу, ибо пользователь быстро получит первые записи, а не будет ждать, когда пол БД на клиента подгрузится. Опять же ускорение, если большая часть объектов не будет использована.

Fuzzymcureenab, не вижу проблемы -- открыл два или сколько надо запросов, собрал объект, показал клиенту, он его сразу видит. Переходим к следующему объекту. Никто ничего не ждёт.

Тебе виднее, конечно. Только на открытие запроса с сортировкой время нужно. Если коллекции большие а критерий отбора слабый, пользователю долго ждать придётся.