Ola estudante.
Está pergunta foi interessante!
Bateu a curiosidade...
O problema que você está enfrentando ao usar agregações com o Sequelize se deve a algumas limitações que o próprio ORM tem ao lidar com SQL complexo, especialmente quando envolve HAVING, GROUP BY, e a necessidade de ordenar ou filtrar com base em valores agregados.
O Sequelize, como ORM, tem como principal objetivo facilitar a abstração de consultas SQL, mas ele não é tão flexível quanto escrever SQL puro, especialmente quando se trata de operações mais complexas como agregações. Ele tenta proteger os desenvolvedores de escrever SQL diretamente, mas em casos como esse, acaba exigindo que o usuário escreva expressões literais para lidar com consultas mais sofisticadas.
No seu caso, o filtro com HAVING no count(curso_id) é algo que o Sequelize não consegue lidar de forma nativa para aplicar ordenação ou filtros diretamente com base no resultado da agregação. Isso ocorre porque, no modelo do Sequelize, ele geralmente trata os attributes, where, group e having como operações separadas e o ORM não consegue encadear essas operações de forma flexível sem recorrer a expressões literais (via Sequelize.literal).
A escolha de não fornecer uma maneira direta de fazer isso pode ser devido a algumas razões:
- O Sequelize tenta abstrair a complexidade do SQL para que os desenvolvedores não precisem escrever SQL puro, mas em casos como o seu, onde é necessário mais controle sobre a consulta, ele não oferece uma maneira direta de fazer isso de forma "amigável".
- Adicionar suporte total para esse tipo de consulta (como ordenar ou filtrar por agregações complexas) exigiria mudanças mais profundas no ORM, e uma forma de garantir que as consultas ainda fossem eficientes, além de fazer sentido com a forma como o Sequelize lida com diferentes tipos de banco de dados e padrões de SQL.
- Consultas com muitas agregações,
GROUP BY, HAVING, e filtros dinâmicos podem ser bastante caras em termos de performance. Como o Sequelize abstrai isso, a implementação de uma solução eficiente e flexível para todos os tipos de consultas poderia acabar comprometendo a performance em alguns casos.
O uso de Sequelize.literal no seu exemplo está correto e é uma forma de contornar essas limitações do ORM. Embora seja uma solução válida, o literal basicamente diz ao Sequelize para não tentar interpretar o código dentro da string e deixá-lo como está, o que é necessário em casos mais complexos onde o Sequelize não consegue gerar a SQL correta por conta própria.
Com isso, você tem o controle total sobre a parte da consulta que precisa de uma expressão específica, mas, ao mesmo tempo, perde um pouco da abstração que o Sequelize oferece. Isso não é necessariamente um problema, mas exige um pouco mais de cuidado, principalmente com segurança (para evitar injeção de SQL).
Em casos como o seu, pode ser que escrever SQL puro seja mais direto e claro. O Sequelize ainda pode ser usado para outras partes do sistema, mas quando a consulta exige um nível alto de personalização, você pode recorrer a SQL nativo usando sequelize.query().
Alguns ORMs (como o TypeORM) podem lidar de maneira mais fluida com agregações complexas, então, dependendo das suas necessidades, você pode querer avaliar outras opções.
O Sequelize não lida bem com agregações complexas em algumas situações por uma questão de design e foco em abstração, o que leva a necessidade de recorrer ao Sequelize.literal ou mesmo SQL puro em certos cenários. Isso não significa que o ORM seja falho, mas sim que ele foi projetado para simplificar a maioria dos casos de uso, deixando exceções como o seu para manipulação direta do SQL.
Se estiver frequentemente lidando com consultas complexas, pode ser interessante avaliar se o Sequelize é o melhor ORM para o seu caso, ou se outras abordagens (como SQL direto ou outro ORM) seriam mais eficientes.
Espero que este post tenha lhe ajudado.
Bons estudos.
