SELECT u.*, COUNT(c.id) as comment_count
FROM users u
LEFT JOIN comments c ON c.user_id = u.id
WHERE u.active = 1 AND c.created_at > NOW() - INTERVAL 30 DAY
GROUP BY u.id
HAVING comment_count > 5;
И его версию в Laravel:
User::select('users.*', DB::raw('COUNT(comments.id) as comment_count'))
->leftJoin('comments', 'comments.user_id', '=', 'users.id')
->where('users.active', 1)
->where('comments.created_at', '>', DB::raw('NOW() - INTERVAL 30 DAY'))
->groupBy('users.id')
->having('comment_count', '>', 5)
->get();
Я абсолютно согласен, что знать SQL для бекендера важно и нужно, но этим все не ограничивается, а еще:
- То что здесь описывается это не ORM, а Query Builder
- Конкретно тут показан Query Builder Laravel, который нельзя назвать эталоном среди QB
- Запросы с группировкой составляют доли процента от обычных запросах в типовых веб-проектах (Аналитические запросы не считаем их вообще делают во внешних системах)
- Сам запрос это еще полдела, в статически типизированных языках еще придется фигачить маппинг если не пользоваться никакими либами
- Чистый SQL это полное отсутствие типобезопасности
- В такой запрос невозможно нормально вставить условные конструкции, например если понадобится фильтрация. Мы сразу попадем либо в склеивание строк, либо в необходимость затаскивать Query Builder
А на картинке к посту пример на drizzle-orm, в котором обеспечивается 100% типобезопасность: проверка всех условий (включая возможность выполнить join), всех операций, всех имен (таблиц и полей). Естественно автокомплит и рефакторинг в наличии.
Естественно это отдельный язык (хотя и крайне близкий к sql), но в современном мире ИИ, подобные запросы могут генериться без проблем, особенно в drizzle-orm, с его описанием схемы.
Плюс хочется сказать, что active = 1 в исходном запросе я не могу рассматривать как не говнокод. Активность должна определяться не флагом, а нормальным статусом. Про флаговое программирование скоро пост в телеге, не пропустите
Ссылки: Телеграм | Youtube | VK