3 ms·
I've only had bad experiences with ORMs. You get implicit behaviours and performance nightmares. SQL isn't hard to write, unless the model is poorly conceived,
by alex_duf 9y ago
I've only had bad experiences with ORMs. You get implicit behaviours and performance nightmares.
SQL isn't hard to write, unless the model is poorly conceived, in which case throwing an ORM at it will only makes things worse.
It really depends on how many tables you have, and how you generate their definition.
Personally I once had to start a fresh project with a large amount of tables, I generated the few CRUD requests I needed on all the tables, and commit them in my VCS. Then when iterating I would update and tweak them manually, either for performance tuning or new features / joins / schema changes etc...
This is not to say ORMs are to throw in the bin, I'm sure they solve some problems, but I've never fund myself in a situation where they would help me more than slow me down.
- grillorafael 9y agoI'm on your side on this. For websites that are completely CRUD based, I believe ORM can help a lot. But if you can about performance/scalability, writing your own queries (Even with some sort of library like knex for example that doesn't hide much/do magic) I believe performs/scale much better.
- sancha_ 9y agoYeah there is learning curve for ORM too. Never blindly use ORM without checking the queries it does to your DB. Enable the logs to see what it does, evaluate them, enhance the slow queries, if you don't know how, change those to raw sql. I would never give up the development speed that using ORM gives me. And from experience there are at most half a dozen queries that I convert to raw sql in a huge project.