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 доступа к БД и СУБД.