FuzzyПарни, ну чего накинулись? Я задал простой вопрос, хотел бы получить простой ответ.
Вам что, никогда не нужно было вытянуть из базы коллекцию объектов, данные которых хранились бы в нескольких таблицах, как я выше описал?
Про гибернейт конечно слышал, но меня интересуют технические подробности -- какие именно селекты выполняются? Может, кто ссылкой поможет?

Решение зависит от СУБД. Оракл поддерживает хранение и извлечение объекта с вложенной коллекцией одним запросом.

JedaitoПодсказка
В базе не хранятся объекты
В базе хранятся их данные

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

Сохранение состояния объета в БД означет копирование значений части атрибутов этого объекта в другой объект, который сохраняется в БД.

FuzzyА если база не поддерживает такой прикол, то как тогда?

Положим есть тип.


Преобразуем объектное представление данных в реляционное.
Получаем две таблицы:


Где oid - системный идентификатор объекта, owner - ключ для связи коллекции и её владельца.

Чтобы реконструировать из БД объект придётся написать два запроса.


into - это ключевое слово PL/SQL означает, что запрос выполняется и возвращает строку в указанную переменную (тут o.a или o.b).
bulk collect - означает, что в o.b будут выбраны все записи, возвращаемые запросом. Если и этого "прикола" нет в той или иной форме, придётся для выборки записей в коллекцию использовать цикл явно.

ОРСУБД Оракл работает примерно так же, только скрывает эти тонкости от пользователя. С Hibernate не работал, но полагаю, что и он работает примерно так же.

mv...
Тут тебе за объектный подход башку живо открутят и заставят
Кодда читать.


Форум называется "Проектирвание БД", и не ограничивается только реляционными БД.

FuzzyJedaito, откуда мнение, что много мелких запросов быстрее, чем один большой? Я раньше думал, что очень наоборот. Серверу же нужно время, чтобы запрос 1) получить по сетке, 2) распарсить, 3) построить план выполнения, 4) запустить и т.д. и т.п. Если запрос один, то всё это нужно сделать один раз. А если их тысячи, то соответственно.

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

2. Что мешает в одном запросе выбрать записи сразу для множества главных объектов, а на стороне клиента рассортировать их по своим коллекциям?

3. Коллекции коллекций это слишком сложно. Используй декомпозицию и ссылки. Пусть объект содержит коллекцию ССЫЛОК на объекты, которые в свою очередь содержат коллекции. Оракл, например, подерживает сети объектов и умеет выбирать объекты по ссылкам ещё до того, как они понадобятся в программе. На клиенте, если потребуется, эту модель можно преобразовать в более подходящую.

4. Не изобретай велосипед. Если тебе что то непонятно, это не значит, что это плохо или не то. Гораздо проще понять существующее отлаженное решение, чем придумать и реализовать без ошибок своё, тем более, что знаний в этой области у тебя ещё маловато.

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


Смотри конкретный API доступа к БД и СУБД.

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

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

FuzzyА что будет, если юзер начнёт по строкам грида щёлкать -- тут уж лучше сразу на клиенте всё иметь, чем для каждого щелчка запрос выполнять. А?

Конечно лучше. Только если пользователь дождётся, когда ему в гриде пощёлкать разрешат.

Лучше (в разумных пределах) увеличить время ожидания реакции на один клик (пользователь и не заметит, что программа дёрнула БД), и быстро выполнить основной запрос, чем регулярно зависать на выполнении всего запроса.

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

Сделай так, чтобы детали без задержки отображались иначе и твой мегазапрос будет работать очень долго. Задержку в 0.5 сек на клик пользователь не заметит. Задержка в 5 сек на все 10 записей будет слегка раздражать. На задержку 50 сек пользователь скажет, что программа не работает.
Хотя выход и тут есть. Запусти фоновую нить, которая, пока пользователь втыкает на результат запроса, доберёт из БД детали.