Uma abordagem interessante para o melhor dos dois mundos é transformar seus dados diretamente no banco, preparando-os para serem mapeados pela linguagem com uma view ou função que retorna exatamente o que o ORM precisa. Junto com triggers para lidar com operações de update ou insert. Dessa forma, o ORM continua cuidando da integração com a linguagem, mas é o SQL puro que faz o trabalho pesado de verdade!

MarceloCesarhá 6 dias

Para seguir essa abordagem, é necessario ter em mente o lugar onde você vai concentrar a carga bruta do seu processento e a escalabilidade da solução. A logica no banco é bem mais difícil e custosa de escalar do que em uma aplicação node. Hoje eu prefiro evitar esse tipo de solução.

clacerdahá 6 dias
Perfeito, Marcelo e Jonatas! Como toda decisão em computação, envolve avaliar os trade-offs. Obrigado pelos exemplos, porque é exatamente isso que vejo: quase sempre uma instância parruda de um SQL Server, MySQL ou PostgreSQL consegue segurar a barra sem muito estresse. De fato, escalar horizontalmente o banco é um desafio que deve ser evitado, mas, mesmo concentrando uma boa parte do processamento no banco, se feito da maneira certa, não costuma ser um problema.
devjonatashá 6 dias

Isso é legal só ter cuidado com overhead, nos lugares que trabalhei muitas vezes esse recurso foi abusado a ponto que o banco rodava numa instancia de 64 cpus e 128gb de ram e sofria em horário de pico. Mas, isso é importante eu cheguei a conclusão na ultima rinha, que passar toda a responsabilidade das transações e validações pro banco melhorava a performance significativamente.

valterpatrickhá 6 dias

É uma boa ideia. Agora uma dúvida, como fazer a migração de ORM para SQL puro?

andersonalvescoelhohá 6 dias
Não sei se tem opção melhor, mas já fiz com script.