[UPHPU] Should I Be Using an ORM?

Justin Hileman justin at justinhileman.info
Tue Jul 21 20:10:25 MDT 2009


Kirk Ouimet wrote:
> Had a couple questions to post this morning. This one is very open-ended.
> I've been looking at PHP ORM's like:
>
>
>
> http://www.doctrine-project.org/



They're absolutely worth your time to learn. They're super rad, and 
usually a bit fickle. And, as others have pointed out, they're not the 
best answer for everything. But they're definitely the best answer for a 
lot of things.

My team is using Doctrine on a PHP platform with a pretty complicated 
model, and the ORM makes traversing that model *far* easier. 
Unfortunately, Doctrine isn't magic. One of my guys threw together a 
bulk import script that could peg a dual-quad Xeon until PHP timed out 
and still not finish... We converted the inner loop into a direct SQL 
insert and the import script could finish in a couple of minutes. So be 
sure to watch for places you can optimize.

That said, we still use the ORM for almost everything. We have over a 
hundred model classes in in the project (~150 DB tables) and we have 
about 18 "normal" SQL queries in the app.

I was curious so I just grepped the source code. Looks like we fall back 
to SQL in only a couple of cases:

* Bulk import, as mentioned above

* Bulk export/reporting -- although a lot of reporting is done through 
Doctrine, because it builds all the heinous joins for us :)

* Pagination -- The version of Doctrine we're using has a bug that 
misreports pagination data... It pages the queries just fine, but lies 
about how many total rows exist, so we ignore what it tells us and ask 
directly via SQL.

* And one other place where I'm pretty sure it should have been done in 
Doctrine. I'll chat with the developer that wrote that code, see if he 
has a good reason for it :)


-- 
justin
http://justinhileman.com



More information about the UPHPU mailing list