4 ms·
I think the advice to not use an ORM* is very misguided. Use the ORM for the 80-90% of queries that are "SELECT * FROM table WHERE id=5" and "UPDATE table SET n
by notJim 14y ago
I think the advice to not use an ORM* is very misguided. Use the ORM for the 80-90% of queries that are "SELECT * FROM table WHERE id=5" and "UPDATE table SET name='jim' WHERE id=5". For the rest of the queries, use your ORM's ability to run custom queries. People who have problems with ORMs are probably not using them correctly.
There was a debate on HN about ORM's a while ago, and one of the most significant comments I read was something along of the lines of "Every project I've ever worked on that 'didn't use an ORM' implemented the same functionality of one in a less-maintainable way."
* Or other object-oriented abstraction layer for database access, ORMs aren't the only option.
- Firehed 14y agoI totally agree. ORMs are not a bad thing and save you from writing the same code over and over again. The key is to understand what it's doing behind the scenes and not be afraid to go in and change it if it's generating stupid queries. Is there some extra overhead? Of course. Probably a lot less than cleaning up the damage from some cowboy coding.
- Muzza 14y ago> * Or other object-oriented abstraction layer for database access, ORMs aren't the only option. What do you mean by this? That you should consider a non-relational database? Clearly any mapping from an OOP language to a relational database is an object-relational mapping.
- notJim 14y agoWhat I meant to say is that ActiveRecord isn't the only pattern.