Если вытянуть данные ни через доктрину ни через чистый SQL

легко не получается, можно ли считать что я хреново спроектировал бд? Или это нормальная практика и просто надо рид модель заставлять работать не с бд, а с эластиком например?

У меня ситуация такая что есть базовые сущности и от них наследуются (или не наследуются, пробовал по разному) более конкретные типы, пример базовых сущностей (они abstract):
Channel{name, description}
ChannelPost{description}

и пример дочерних:
YoutubeChannel{..., videos: YtVideo[], followers: int, views: int}
TiktokChannel{..., videos: TtVideo[], followers: int, following, likes}
YtVideo {..., views, likes, dislikes, comments}
TtVideo {..., views, likes, comments}

И вот если мне надо получить список всех каналов (и ютуб, и тикток) и отсортировать их по кол-ву подписчиков DESC и отдать на фронтенд то с SQL или доктриной у меня получается что то вроде:

$allChannels = [...$ytChannels, ...$ttChannels];
usort($allChannels, fn ($ch1, $ch2) => $ch2->followers <=> $ch1->followers)
// todo map result to ChannelResource[] and return
то есть даже на простых требованиях, и даже если есть общие интерфейсы в этих сущностей уже возникают какие то трудности при выборке, не говоря про более сложные запросы вроде "вывести каналы в которых среднее кол-во просмотров на последних 5 видео более 100", напрашивается какой то индекс, смотрю в сторону эластиксерч.. я в правильную сторону двигаюсь или надо пересмотреть структуру бд в первую очередь?

Потому что у меня ощущение что я стою на месте, уже попробовал и через DiscriminatorMap, и просто отдельные интерфейсы вывести для Channel + ChannelPost и хранить всё в отдельных таблицах, думал так же о json полях, и сейчас пришел к тому что при записи всё настолько красиво что мне хотелось бы этот вариант оставить, но блин хочу удостовериться что смогу быстро считывать и мапить эти данные

1. наследование сущностей "может быть не так уж плохо" когда весь стэйт private и наследники не имеют доступа к общим частям напрямую. Тут всеравно композиция работает лучше но "инфраструктура накладывает ограничения потому пойми и прости". Если это не так то это разные сущности и ты уже делаешь чернь. 2. ты не привел примеров запросов. Ощущение что ты вытаскиваешь всю базу и фильтруешь в php... с этой точки зрения "явно чет не так" и тут ничего про рид модель не надо даже упоминать. 3. то о чем ты говоришь это банальный репортинг и юзай для этого SQL. Возможно стоит разобраться какие фичи есть в SQL + вопрос еще какая СУБД. Какой-нибудь postgresql с задачами вида "выведи мне количество подписчиков по всем вот этим штукам" на SQL решается отлично.

1. Ну понятное дело что private, наследникам нет дела до родительских пропертей, с этим всё в порядке 2. Запросы вида SELECT id, subscribers FROM tiktok_channels WHERE owner_id = x UNION SELECT id, subscribers FROM youtube_channels WHERE owner_id = x- да в этом случае всю бд вытаскиваю ограничение только по каналах одного владельца, ну их не будет много (даже если 20) по этому сортировка на пхп, до более сложных вещей пока не дошел даже так как уже такая выборка сеет сомнения что я в правильном направлении двигаюсь 3. Субд постгрес последняя, да вот за напоминание про вюшки спасибо, надо в эту сторону посмотреть

ну тип никто ж тебе не мешает делать... SELECT summary.id, summary.type, subscribers FROM ( SELECT id, 'youtube' as type, subscribers FROM ... UNION SELECT id, 'tiktok' as type, subscribers FROM ... UNION SELECT id, 'instagram' as type, subscribers FROM ... ) summary WHERE summary.subscribers > 100 ORDER BY summary.subscribers