Usar ORM é uma forma de dizer que te preocupas mais com os objetos do sistema do que com o desenho da base de dados.
E isso é um trade-off perfeitamente razoável para uma boa parte das cenas que desenvolvemos. Mas torna-se problemático em sistemas de grande escala, onde não podes simplesmente entregar o desenho da tua base de dados a uma camada de abstracção.
A base de dados não é apenas o sítio onde os teus objetos acabam por ser guardados. O schema, os índices, as relações e as queries fazem também parte da arquitectura do sistema.
Por exemplo, quando estava a reescrever os nossos sistemas de Python para Go, percebi que as queries subjacentes não faziam fit com a nova implementação. A forma como a ORM tinha modelado as tabelas em Python não podia ser automaticamente traduzida para os objetos em Go.
Tive de adaptar as queries a nova ORM.
ORMs não seguem um standard universal sobre como as relações entre objetos devem ser traduzidas em operações na base de dados. Por isso, não são facilmente portáveis de uma linguagem para outra.
Algumas ORMs fazem múltiplos requests onde um simples JOIN poderia resolver o problema numa única query. Com listas, isto pode facilmente transformar-se num N+1 problem.
Se cada registo tiver várias relações filhas, podes acabar com dezenas ou centenas de queries quando a base de dados poderia responder à mesma pergunta com uma query relacional devidamente desenhada.
Já tive vários problemas de performance por causa de ORMs. SQLAlchemy por exemplo tem 17 vulnerabilidades de segurança que meio que nunca serão resolvidos, e tem problemas de gerir conection pools.
Será que uso? As vezes sim… quando tenho umas operações críticas, escrevo as queries manualmente. Sou híbrido
@xellseaa Quanto mais próxima a pessoa maior é a inveja. Difícil invejar desconhecidos.
Sobre o assunto I recommend: Inveja, o pecado envergonhado, Leandro Karnal.
Self-diagnosed anxiety, bipolarity, PTSD or depression are not excuses for your impatience and your grandma would probably slap you for it, millennial fool.