How does one use the RDBMS in a performant way on

问题:

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?

回答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.

回答2:

Some points need clarification:

1. Like you said - Zend_Db_Table doesn't implement "auto join", in another way could be called eager loading. If you need such a functionality, take a look at PHP-AR
2. It's possible to implement eager loading in Zend_Db_Table on your own - I spent some time thinking about it, and I'm pretty sure, that it can be done. But I don't have time to do it :)
3. But looking from the other side - Zend_Db_Table is a part of model of your app. You should worry how your data are fetched, you're interested in data itself. Going further - if you use fat model, thin/skinny controller attitude, you can implement join that you need inside method in quick way, which will be sufficient for most of cases.
   Example: http://pastebin.com/pNwideWf (I'm linking to paste bin, because code formating don't work properly for me in editor).

Unfortunately, using that aproach, you won't be able to save data in joined tables, and you must watch out with column names: you can't do $row->joined_table->field_from_joined_table - instead of this you can $row->joined_table_field_from_joined_table.

Summarizing - if you want performance, use fat models as mentioned before - store all logic of fetching/filtering data in model classes, in your case Zend_Db_Table.

回答3:

Take a look at NotORM database layer. That might do what you need ;)