Comments 4
На уровне ORM это очень грубо, буквально черно-бело. Все или ничего. Если делать оптимальнее, то метод, который выбирает данные чилдовой сущности, должен иметь на входе список первичных ключей родительской сущности, для которых выбираются чилдовые. Далеко не всегда их нужно выбирать для всех ключей родителей.
В рудиментарном случае - это единственный ID (например, для показа/редактирования экземпляра родителя), в более сложном (или статистически-частом) - например, вызов чилдов только для ID тех родителей, которые в данный момент рендерятся на клиентском экране.
Вычитывать "все для всех" часто бывает избыточным - а интегральная производительность системы определяется не трудоемкостью отдельно взятых операций, а трудоемкостью их статистической смеси, наблюдаемой при рабочей нагрузке. Например, если клиент статистически не скроллит вниз выдачу дальше первых 5-6 элементов - то и выбирать чилдов дальше 5-6 без специального события (скролла вниз) заранее не нужно. И что в данном случае будет лучше (если у нас нет точных средств, которые я описал, а есть только "все или ничего") - совсем не очевидно.
С книгой пример не очень удачный. А вдруг это сборник с десятком авторов да еще и парой десятков жанров. Ну да это мелочь.Было бы неплохо намекнуть что иногда можно и даже нужно отойти от жесткой привязки к инструментам.
Если есть много ко многому, к примеру books - book_authors - authors. То можно одним запросом сразу выбрать данные о книге и его авторах в стандратной json строке. И объект можно сразу собирать целиком. Пример в нотации SQLite:
select
b.id, b.title,
(select json_group_array(json_object(a.id, a.name))
from
book_authors as ba
join authors as a on a.id = ba.author
where
ba.book = b.id) as authorsJSON
from
books b
Стратегии извлечения FetchType и N+1