cli - orm php

¿Cuándo debería usar doctrine ORM y when zend-db-table?

Question

En términos de escala de proyecto, doctrina vs zend-db-table velocidad y rendimiento, ¿cuándo debería usar la doctrina dentro del proyecto Zend, y cuándo zend-db-table?

Answer 1

Cualquier marco ORM le brinda beneficios para la productividad de desarrollo, no para la eficiencia del tiempo de ejecución. Doctrine no es diferente de Zend_Db_Table en este sentido.

Si elige entre Doctrine y Zend_Db_Table, elija según las características que hacen que sea más fácil o más rápido escribir el código.

Ningún marco ORM puede hacer consultas de base de datos automáticamente más rápido en el caso general. Si necesita consultas de bases de datos de alto rendimiento, debe aprender a codificar las consultas SQL y diseñar su esquema e índices para respaldar el rendimiento dadas las consultas que necesita ejecutar.

Answer 2

Doctrine lo ayuda a definir una mejor lógica comercial y ORM, pero es un asesino de rendimiento absoluto en términos de memoria y CPU. Zend table gateway es 5 veces más rápido que Doctrine. Y puede extender la puerta de enlace de la tabla Zend para eliminar algún analizador de tipo de datos y eso le dará una mejora de 5x más conservando aún el beneficio de un ORM simple. Aquí está mi clase FastTablegateway:

<?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 3

Use lo que sea que le resulte más cómodo y lo hará más eficiente. Usted y sus compañeros desarrolladores son probablemente el recurso más costoso, y probablemente sea más barato comprar hardware adicional, si es necesario, que tener que preocuparse por posibles consideraciones de rendimiento futuro.

Por supuesto, aún necesitará realizar optimizaciones básicas de la base de datos, como la creación de índices razonables, etc. Pero creo que esas "optimizaciones" son obvias.

Answer 4

si tiene muchas consultas SQL, y falta de conocimiento (sin saber nada sobre el almacenamiento en caché o la optimización de consultas, etc.) y la falta de tiempo, Zend_DB es más rápido y fácil de entender y es lo suficientemente bueno para USTED, el que está en falta de conocimiento y tiempo y quiere ser lo más rápido posible.

pero si quieres una doctrina ORM asesina gana. pero requiere más tiempo y energía para ser utilizado de manera eficiente.

y si quieres ser un asesino de DB, saldremos del tema. es diferente. y no se basa necesariamente en las herramientas que usa. (Algunos asesinos DB probablemente usan PDO y sus propios modelos, ¿quién sabe?)