When should use doctrine ORM and when zend-db-tabl

Question

In terms of project scale, doctrine vs zend-db-table speed and performance, when should I use doctrine inside Zend project, and when zend-db-table?

Answer 1

Any ORM framework gives you benefit for development productivity, not runtime efficiency. Doctrine is no different from Zend_Db_Table in this regard.

If you are choosing between Doctrine and Zend_Db_Table, choose based on the features that make it easier or faster to write the code.

No ORM framework can automatically make database queries faster in the general case. If you need high-performance database queries, you should learn to code SQL queries, and design your schema and indexes to support performance given the queries you need to run.

Answer 2

Use whatever you are most comfortable with and will make you the most efficient. You and your fellow developers are probably the most expensive resource, and it's probably cheaper to buy additional hardware, if needed, than you having to worry about possible future performance considerations.

Of course, you will still need to perform basic database optimizations such as creating sensible indexes etc. But I feel that those "optimizations" go without saying.

Answer 3

Doctrine helps you define a better business logic and ORM, but it is an absolute performance killer in term of memory and CPU. Zend table gateway is 5x times faster than Doctrine. And you can extend Zend table gateway to remove some data type parser and that will give you an improvement of 5x more preserving still the benefit of and simple ORM. Here is my FastTablegateway class:

<?php
namespace Application\Libraries;

use Zend\Db\TableGateway\TableGateway;
use Zend\Db\Adapter\AdapterInterface;
use Zend\Db\ResultSet\ResultSetInterface;
use Zend\Db\Sql\Select;
use Zend\Db\Sql\Sql;

class FastTablegateway extends TableGateway{

    protected $mysqli_adapter = null;

    /**
     * Constructor
     *
     * @param string $table
     * @param AdapterInterface $adapter
     * @param Feature\AbstractFeature|Feature\FeatureSet|Feature\AbstractFeature[] $features
     * @param ResultSetInterface $resultSetPrototype
     * @param Sql $sql
     * @throws Exception\InvalidArgumentException
     */
    public function __construct($table, AdapterInterface $adapter, $features = null, ResultSetInterface $resultSetPrototype = null, Sql $sql = null, $mysqli = null)
    {
        $this->mysqli_adapter = $mysqli;
        parent::__construct($table, $adapter, $features, $resultSetPrototype, $sql);
    }


    protected function executeSelect(Select $select)
    {
        $time = time();
        $selectState = $select->getRawState();
        if ($selectState['table'] != $this->table) {
            throw new \Exception\RuntimeException('The table name of the provided select object must match that of the table');
        }

        if ($selectState['columns'] == array(Select::SQL_STAR)
        && $this->columns !== array()) {
            $select->columns($this->columns);
        }

        //apply preSelect features
        $this->featureSet->apply('preSelect', array($select));

        if(!$this->mysqli_adapter){
            // prepare and execute
            $statement = $this->sql->prepareStatementForSqlObject($select);
            $result = $statement->execute();
        }else{
            $q = $this->sql->getSqlStringForSqlObject($select);
            //var_dump($q);
            $result = $this->mysqli_adapter->query($q);
            $result = is_object($result) ? $result->fetch_all(MYSQLI_ASSOC) : [] ;
        }

        // build result set
        $resultSet = clone $this->resultSetPrototype;
        //var_dump(is_object($result) ? $result->num_rows : 'A');
        $resultSet->initialize($result);

        // apply postSelect features
        //$this->featureSet->apply('postSelect', array($statement, $result, $resultSet));

        return $resultSet;
    }

}

Answer 4

if you have a lot of SQL queries, and lack of knowledge (knowing nothing about caching or query optimization, etc.) and lack of time use Zend_DB it is faster and easier to be understood and it is good enough for YOU - the one who is in lack of knowledge and time and want to be as fast as possible.

but if you wanna a killer ORM doctrine wins. but it requires more time and energy to be used efficiently.

and if you wanna be a DB killer, we're gonna go off topic. it is different. and it is not necessarily based on what tools you use. (some DB killers probably use PDO itself and their own models, who knows?)