Re: Zend_Db_Table time overhead - about 25%

Bill Karwin wrote:

In fact, if performance is the only concern, you shouldn't be using an RDBMS at all -- you should be managing data using a custom storage module that you write, specialized to your application.  Also, you shouldn't be coding in PHP in the first place -- you should be writing all your code by hand in assembler.

Hi Bill, thank for the answer, you are of course right with this statement, but when the performance is not the only concern, but it is main concern - what is the situation then? Coding in assembler is not a question at all, we are writing a web applications, so we have choosen PHP for this. We want some coding standarts and some structure to follow, so we use Zend Framework. It have not small overhead alone, so when we have choosen to use Zend Framework we already have made some trade-off between speed and development convenience.

But. Most of the web applications make heavy use of database. While scattering your code with SQL queries is bad and with no doubt you should avoid it, placing direct SQL queries in some class in your Model layer is not bad design for me.
I don't want to start a flame here, I just want to share some thoughts and to see the opinion of the others. My point of view is that insisting to use another and another layers of abstraction just for the abstraction itself does not lead to good things. Table Gateway and Row Gateway patterns have their use, but they have limitations also and are not the best solution for everything. For example when we want to represent tabular data and edit it row by row this is great approach. Also if we want to have some kind of code generation, for example for quick generation of admin modules, allowing editing, inserting and deleting of rows in and from DB tables the Table Gateway and Row Gateway pattern is nice. Together with Zend_Form this can be very powerfull way to quickly generate very complex applications. But when it comes to speed, writing in assembler is not the only way to improve it..