+

Если вытянуть данные ни через доктрину ни через чистый 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 полях, и сейчас пришел к тому что при записи всё настолько красиво что мне хотелось бы этот вариант оставить, но блин хочу удостовериться что смогу быстро считывать и мапить эти данные

$allChannels = [...$ytChannels, ...$ttChannels];
usort($allChannels, fn ($ch1, $ch2) => $ch2->followers <=> $ch1->followers)
// todo map result to ChannelResource[] and return

1. наследование сущностей "может быть не так уж плохо" когда весь стэйт private и наследники не имеют доступа к общим частям напрямую. Тут всеравно композиция работает лучше но "инфраструктура накладывает ограничения потому пойми и прости". Если это не так то это разные сущности и ты уже делаешь чернь.

2. ты не привел примеров запросов. Ощущение что ты вытаскиваешь всю базу и фильтруешь в php... с этой точки зрения "явно чет не так" и тут ничего про рид модель не надо даже упоминать.

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

можно так же делать вьюшки которые агрегируют статистику и упрощают тебе доступ к данным. В любом случае ORM нужны на запись а не на чтение и уж тем более не для репортов

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 id, subscribers FROM tiktok_channels WHERE owner_id = x
UNION
SELECT id, subscribers FROM youtube_channels WHERE owner_id = x

ну тип никто ж тебе не мешает делать...

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

есть кейс - например тебе надо сначала вывести одни записи. потом другие потом третьи - по статусу например (обычная штука с историей заказов скажем) - возможно тут лучше вообще 3 запроса сделать а не 1 сложный с юнионом.

Количество запросов в базу не имеет значения. Один или 100. Важно что бы количество этих запросов не зависело от данных (1+N)

кстати да, красиво, останется вопрос производительности, но он меня пока не сильно волнует

это будет в любом  случае быстрее чем "сортировать пыхом")

или что хуже - фильтровать. С сортировкой еще могут быть кейсы когда да проще пыхом и разница в производительности не важна

Большое спасибо за пищу для размышлений, пошел пробовать писать sql и читать про views, может как раз без эластика обойдусь

Быстрый способ наклепать ридмоделек под всякое- это вьюшки. Если запрос большой и тяжёлый во вьюхе , то можно сделать materialized view, но её надо обновлять раз в некоторое время

А подскажите пожалуйста ,как вы работаете с полями decimal ?

Value object

Целые отдельно, дробные отдельно

Смотря для чего
Деньги храните или координаты?

огласите список операций над этими полями пжалуста

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

Но чаще всего молимся чтоьы работало без тестов 😂

Время, потраченное на молитвы, можно было бы потратить на написание тестов) это намного более разумный расход времени))