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.

I 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.

> * 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.

What I meant to say is that ActiveRecord isn't the only pattern.

Personally, one of my favourite discussions is Laurie Voss' "ORM is an anti-pattern": http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern

The key criticism in that article seems to be "ORMs are imperfect abstractions for SQL." Who the hell cares? This is the real world. We don't need perfect abstractions.

Which, really, should be "ActiveRecord is an anti-pattern"

It could be as simple as the performance loss incurred by an ORM is greater than the benefit of using it. You have PDO with PHP, which can be used quite adequately as an ORM itself (you can fetch a tailored SQL query into a class as opposed to working with basic arrays).

I'd argue that, in some cases, an ORM is only used as a reaction to the separation of concerns. Writing SQL mixes up your languages, so why not try to build that SQL in the language you're working with? Or maybe SQL is considered too difficult.

I quite like having full control over a 'raw' query without requiring an ORM's opinion on how it should be built.

PDO doesn't handle mapping of nested relationships, though which is where it falls down when compared to ActiveRecord implementations. For example I want to fetch an author and all of the author's books in a single query then loop over and print out author name, and each book. A standard ActiveRecord ORM will give you an array of authors where each author contains an array of books, where as with PDO you're still left to manually detect a change in author by a change in the primary key which is more complex than just writing a nested for loop.

Forgive me if I misunderstand, but if you can't pull this off in a single SQL query, then ActiveRecord can't either. It just hides the fact it's performing several queries to get what you want.