Scaling PHP Book: I will teach you to scale PHP to millions of users

Re:Scaling PHP Book: I will teach you to scale PHP to millio... by notJim on Wednesday June 06, 2012 @12:35AM (#4072438)

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.

[ Parent | on HN ]

Re:Scaling PHP Book: I will teach you to scale PHP to millio... by Firehed on Wednesday June 06, 2012 @02:03AM (#4072633)

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.

[ Parent | on HN ]

Re:Scaling PHP Book: I will teach you to scale PHP to millio... by Muzza on Wednesday June 06, 2012 @08:14AM (#4073317)

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

[ Parent | on HN ]

Re:Scaling PHP Book: I will teach you to scale PHP to millio... by notJim on Wednesday June 06, 2012 @10:28AM (#4074004)

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

[ Parent | on HN ]