и?

25 таблиц и 10к запросов?

есть такая вещь как lazy initialization

опишите проблему, а то какие-то ваши отрывочные воспоминания о какой-то непонятной проблеме для которого либо 10к запросов, либо всю таблицу на клиент и фулскан

И кого с чем вы там собираетесь соединять? Хотите плоский датасет из 25 таблиц с последующей обработкой оного на клиенте?

+

данные агрегата друг с другом ну але

select d.*, a.* from documents d
left join document_assets da on da.document_id = d.id
where d.id = :id

и вжух, hibernate не сделает N+1 запрос для подгрузки ассетов

такое ощущение что достали документ, а лейзи мапинг хибернейта начал клепать по одному запросу на каждую айдиху

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

в чем здесь проблема непонятно)

все непонятно) как вы выжили с 10к запросов на каждый документ?

ок, проехали :)

с N+1 столкнулись? Научились в гибернейте ее решать? Если да, то поздравляю, вы узнали что-то новое для себя

Ога, флаг в руки, и так 25 раз, из них часть рекурсивные по иерархиям компоновки товара :)

В банковском секторе пишут квери по 1000-2000-3000 линий и ничего

Ога, для выдачи денормализованных датасетов из 25 внешних соединений таблиц с последующими сканированиями оного на клиенте для распихивания прибывших данных по объектам :)

Зачем на клиенте сканировать ?

И я пропустил момент что именно к этим "воспоминаниям" привело...

Есть очень простая и понятная ментальная модель среднестатистического разработчика.

Сущности - ряды табличек
Репозитории - таблички

Дальше из этой ментальной модели рождаются все остальные проблемы. Как дробить "сущности" - ну вспомни как в ВУЗах учат нормализации или там эти типичные булшитные задачки в стиле иерархии "студент-учитель-человек" бла бла.

Надо для UI вытащить условные посты с комментами - пост у тебя корень, потому в репозитории постов делаем "джойн" аля связь между двумя репозиториями. global coupling понесся.

Как-то когда речь идет о сложных составных репортах убедить что это надо выносить "отдельно" достаточно просто, так как не понятно кто корень. Просто куча данных.

Если же попытаться подать список постов и комментов как "репорт" то корень явно виден и "почему это не должно быть в PostRepository"? Ну и важный аспект - все эти гибернейты забирают с разработчика такую мерзскую штуку как нормализация резалт сэта. Что приятно и легко. С репортами "обычно" нет такой острой проблемы - ты всеравно будешь в CSV условный это выплевывать и опять же проще убедить.

Ну и когда народу в туториалах про N+1 рассказывают то часто можно придти к выводу что "достать все одним запросом есть цель".

В целом проблема что у нас есть вот эта модель "репозиторий = табличка" (или коллекция если монга) и какое-то оч упрощенное восприятие что данные ходят туда сюда одинаково. Поскольку "за репозиторий" никто особо не смотрит и не разбирается как данные в реальности связаны и как юзаются для чего - получаем "текущую абстракцию".

Во всяком случае это мои наблюдения за последние 5 лет.