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
_______________________________________________
UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net
