Question

There’s this constant war going on in my thoughts when I work on a Zend Framework project — good application design mandates that the number of database queries be minimized. Each query is expensive in terms of both latency and RDBMS calculation time. And Zend_Db_Table encourages you to make lots of queries — there’s no built in way to JOIN with other Zend_Db_Tables, for example. And there’s no way to extract the name of the underlying table given an instance of Zend_Db_Table, which makes writing Zend_Db_Select queries in terms of Zend_Db_Table difficult. In a sense, Zend_Db_Table encourages you to implement features the RDBMS already provides in PHP, which is obviously suboptimal.

On the other hand, Zend_Db_Table makes tables behave a bit more like native PHP objects by abstracting away the SQL queries themselves. The user need not worry about quoting all that often, and SQL operations are exposed as simple PHP methods.

What would be nice would be something like Zend_Db_Table, but which would use lazy operations (as Microsoft does with LINQ-to-SQL/Entity Framework/etc.) in order to condense what seems to be multiple PHP statements into a single (or at least fewer) RDBMS quer(y|ies).

Does such a thing exist? Is it included with Zend or not?

Answer 1

I agree with you that Zend_Db_Table sometimes acts as a hammer in search of nail. It’s not always the most natural tool for writing customized, performant queries with joins. It seems to me that Zend_Db_Table is optimal primarily for a single table without joins. But it is still possible to do optimal db querying using aspects of the Zend_Db component.

As noted by @singles, all this db access should probably be buried inside a model (for an ActiveRecord type of approach) or in a mapper (for a DataMapper approach) or in an entity manager (like Doctrine2) does.

For exmaple, your custom BlogPost model could be fed an instance of a custom BlogPostDataAccess which would be fed an instance of Zend_Db_Adapter. All your queries – including your optimized joins – would reside within the BlogPost_DataAccess class. The SELECT queries in the DataAccess class could be written using soemthing like (pseudocode):

$select = $adapter->select()
        ->join()
        ->join()
        // etc.
        ->join()
        ->where()
        ->limit()
        ->order();

See what I mean?

Update

How about a $tableMap member variable? Something like:

public static $tableMap = array(
    'posts'        => 'table_posts',
    'users'        => 'table_users',
    'categories'   => 'table_categories',
    // etc
);

Then in your queries, you could use something like:

$select = $adapter->select();
$select->from(self::$tableMap['users'], array('name', 'email'));

Maybe add methods called setTableMap($tableMap), getTableMap(), getTable($k), setTable($k), store the initial mapping data in a config file and then populate the static member during bootstrap.