Introduction to Zend_Db
Friday, October 31. 2008
thx lorna, nice and short introduction. i wasn’t aware of the table-row-class… this will make my devlife a lot easier!
Yuck :) I really can’t see the point of designing an ORM that ends up looking like that.
butters: glad to hear it helped :)
Stuart: The very nature of what I do means I work with whatever I need to, and I don’t get to choose! I’d be interested to see examples of how it works in other systems though
Thank you for this post. It’s very clear and helped solidify my thinking of the workflow from the database to read an example that is linearly stated.
Zend_Db_Table is not a model class and never should be used strictly as a model class. It may seem convenient to work directly with the table classes in your controller but will only get you in trouble in the end. You should either construct your own model classes which use Zend_Db_Table or you can read this: http://www.zacharysnow.com/2008/06/20/zend_db_table-as-a-model/ for a semi work around.
Interesting site on ORM:
http://ifacethoughts.net/2008/11/06/on-misusing-orms/
diamondTears: glad to have cleared things up a bit.
Zachary: I am now further into my project than I was when I wrote this post and I repent entirely the decision to inherit from the table_row classes!! I’ll be writing another post when I’ve settled a bit more with the whole concept but suffice to say I’ve got ordinary models with SQL or use of Zend_Db stuff in the various methods and that is working much better! They do say "you live and learn" and I did on this one :)
Simon: Thanks for sharing the link. I agree that ORMs can be more hazard than help – especially since I know a lot more about databases than about PHP frameworks.
I have made the same mistake on my project(before I even read this post, so this is not your fault :-) ). I inherit EVERY classes from the table_row classes.
Now I can see there is something wrong with the whole concept but I’m too deep in the projetc to change that. Anyway I would be glad to hear more from you about that.
Tanks for this Post
The thing that gets me is this: in any non-trivial project, a model doesn’t just interact with MySQL. Models end up in caching layers, in sessions, and interacting with users through forms, query parameters, and of course APIs.
Given all that, any sort of model that is designed around tables and rows just seems ultimately to be missing the point :)
Best regards,
Stu
Great post. I love it when someone simplifies things like this. thank you
Thanks for this posting. I would like to question your assertion that you should have an intermediate class functions such as date formatting. Surely this kind of function should be implemented as a method on an independent helper class. Do you agree?
Karim: You make a good point. In general, if I’m writing formatting code that is specific to a particular object, I’ll make it a method of the object, just to keep everything together. But if its something like formatting a date which will happen in lots of places, then yes I would want to use a helper. The examples in my post were really too simple – just because I wanted to give an outline without any distractions
Therein lies the rub. When you do ORM at this level it seems almost mechanical until you realize that it introduces a lot of application layer cruft in your more complex models that could have been done by queries.
I’m pretty good at queries, and while I ordinarily say don’t worry about preformance at first, the thing will preform better ultimately if we let the db server do complex queries rather than selecting a whole bunch of stuff and filtering it through a lot of these table objects in the app. When you do it this way you hardwire it into your model at a low level and it is not so easy to optimize.

