и потому всё выглядит так, будто это в самом деле разные объекты
там большая табличка на 30+ полей и иногда нужен один набор, иногда второй
по хорошему это надо было бы разбросать по разным таблицам, но это получится попозже

ну если такое легаси, то и фиг с ним

для разделения сущности, при этом хранение в одной таблице можно применить Embeddable классы, так будет проще рефакторить и вообще поддерживать

Embedded не то(

тогда страдай ))

а как вообще решаются такие кейсы? вот есть сущность, например, Car. у неё есть связь oneToMany на картинки. Управление этими картинками вынесено в отдельный кусок проекта, там своя мутная логика, она более-менее изолирована и никому не мешает.
Больше в проекте нигде эти картинки не используются, это такая вещь сама в себе.

И что, по всему проекту, где мне нужна инфа о этом Car'е - я везде могу вытащить эти картинки? А какой смысл всему проекту знать об этих картинках?
Embedded не подойдёт потому что мне нужно со связями разносить.
Разбивать сущность на осмысленные куски говорят тоже муветон. Как сами решаете такие затыки?

Или строго наоборот - зачем куску, который занимается картинками, знать ещё о 30+ методах, которые не используются при управлении картинок?

Можно, конечно, собрать всё в одну сущность (сейчас так и есть) и через связи половину базы вытащить. Но можно же как-то и разбивать, чтоб не путать мух с котлетами.
Вот я собственно и спрашиваю как можно разбить так, чтоб и связи тоже дробить

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

почему на чтение плохо доктрина?

чтение вообще пофиг, чтение сделано мускулом, работает на ура

а чем оно хорошо?

а зачем изображению знать про Car?

что у нас - объект, а не массив данных из хранилища

незачем, вопрос остаётся в силе)

ну так убить эту связь

а нам нужен объект на GET-запросе? зачем?

бенчмарки не делала, но говорят тормознутей и тянет все что не попади, как и в даной ситуации

пусть Car знает про Image, но не наоборот

в чем тогда проблема?