2 ms·
I've used both repeatedly, and I will never use an ORM again. It's never gone well. Conversely, direct SQL read/write works great for a variety of applications
by hot_gril 4y ago
I've used both repeatedly, and I will never use an ORM again. It's never gone well. Conversely, direct SQL read/write works great for a variety of applications if you do it right. No complaints about that. Pretty convinced the only appeal of ORMs is for people who want OOP everywhere or just don't want to learn SQL, but it's worth learning SQL and the basics of a normalized DB schema.
Sometimes it's supposed to be about abstracting away the DBMS. But the interface between your code and the DBMS is usually very "wide," plus you might be working around performance concerns. You can try to abstract it away with an ORM, but the abstraction will be just as wide, and now you have another layer introducing limitations and performance issues. So it seems to go against basic software design, but you really have to accept that your backend code is going to be married to your DBMS. It's either that or marry the ORM.
Forgive the title, but I also agree with the points here: https://blog.codinghorror.com/object-relational-mapping-is-the-vietnam-of-computer-science/ https://blog.codinghorror.com/object-relational-mapping-is-t...
And if your ORM isn't a super well-supported thing, good luck. When I started my new job years ago, they said they were starting to use a custom DB/ORM-as-a-service thing maintained by a partner team. That team had great engineers, but it was simply too big a project for them to essentially build a DBMS on top of a DBMS, so it was a mess. I tried to act like this was ok until one day I showed a skip-manager some unfixable race conditions that broke our whole application. Our team got new devs who also complained about it. It also happened to not comply with some unrelated department mandate, which gave me the justification to take the reigns on our team bailing us out of that. Took a full codebase rewrite where I just gave them a regular SQL database. I'd say it cost us an entire year of development in the end.