Re: [fw-general] Anyone using/planning to use Zend_Db_Table?

[Abu Hurayrah]

Nick, At my workplace, I implemented an ActiveRecord-like class (named db_object) that used to work exactly as you've described - namely, prior to every query to fetch actual record data, a call to SHOW COLUMNS FROM table name would be required.  Very quickly we realized that this was doubling the number of queries needed to do anything. We got around this by actually caching the result of the SHOW COLUMNS call per each request, and then simply checking for the presence of this key (the table name) within the cache.  If it existed, we used the cached result.  This boosted performance significantly, such that, per page request, only one call to the table structure was needed for each table, no matter how many records from that particular table were needed. One important point to emphasize is that, while initially ORM (I think this is the term thrown around on the list - Object-Relational Mapping) may take a performance hit in simple situations due to operational overhead, in larger & more advanced setups it can be optimized in far more ways than a traditional setting, because you can abstract out the retrieval and cache entire result sets, or composed pages, and so on.  Additionally, ORM will enforce consistent queries, enable (but not force) higher security standards due to consistency of query structure and actually lets the programmers work on writing their code efficiently, and the database blokes (such as myself) can work behind the scenes transparently optimizing the internals of how the object-oriented abstractions work.  In fact, one of my upcoming projects is to allow db_object to transparently access foreign keyed records much like Ruby on Rails' ActiveRecord does.  This would have been unthinkable had we not abstracted the interface out to an object. Just recently, I added a db_recordset object to our database tools, which implements the PHP5 interfaces of Iterator, ArrayAccess, & Countable.  I hoping to try to contribute a similar enhancement to the existing Zend_Db_Table_Rowset object, because the usage through these interfaces is very intuitive, at least for me. Let it be known that I am not advocating completely dropping performance optimization in preference of abstractions, but rather, I would like to say the two are not mutually exclusive, but rather, they are complimentary in a well-designed system, and can yield a superior result when combined intelligently. *descends from soap box* Nick Lo wrote: I've just recently had time to test out Zend_Db_Table and while I realise it has a new proposal (which I can't get to right now as the wiki appears to be down) I'm curious as to how many are really using or planning to use it? I think the main thing that I don't feel comfortable with about its (and ActiveRecord type) approach is the need to call DESCRIBE before it can operate. This means that even the simplest query becomes at least 2 queries and seems like an unnecessary overhead. I just wonder quite what kind of apps are in need of this kind of thing. Small apps would surely just be able to work more directly with the SQL and larger apps would surely suffer performance issues. It would make sense to have some kind of cache of the database info rather that be querying it afresh each time and only update the cache when the database itself changed. Anyway, I am interested in any discussion about this particularly from those who have a database admin leaning and have opinions about its efficiency. Thanks, Nick