Doctrine2 ... ¿Mejor modo de hidratación?

Question

Estoy diseñando un sistema de reserva de habitaciones que tiene nueve entidades, todas relacionadas entre sí. En este caso específico estoy recuperando 10-30 filas de la entidad entry que tiene 25 propiedades. Cada entrada tiene un room que tiene 10 propiedades. Necesito toda la información de entrada, así como entry->room->id y entry->room->name. Pero parece que la doctrina está cargando todo room cuando uso Query::HYDRATE_ARRAY. Parece ser la carga lenta en Query::HYDRATE_OBJECT más fácilmente.

Por lo tanto, me pregunto si se usa el modo de Query::HYDRATE_OBJECT es más rápido o "mejor" que Query::HYDRATE_ARRAY/Query::HYDRATE_SCALAR/Query::HYDRATE_SINGLE_SCALAR. Como estoy reutilizando un código anterior, me gustaría usar HYDRATE_ARRAY pero solo si no ralentiza la aplicación.

Answer 1

Mis 2 centavos:

HYDRATE_OBJECT es mejor para cuando se va a utilizar una gran cantidad de lógica de negocio con sus objetos. Especialmente si estás haciendo mucha manipulación de datos. También es probablemente el más lento (dependiendo de la situación).

HYDRATE_ARRAY suele reservarse para cuando solo necesita un resultado y 1 grado de datos relacionales y se va a utilizar solo con fines de impresión/visualización.

HYDRATE_NONE es otra que utilizo cuando solo selecciono un subconjunto de datos muy pequeño (como uno o dos campos en lugar de toda la fila). Esto se comporta de manera similar a como lo haría un resultado de consulta sin formato.

Esto también podría ser de interés http://www.doctrine-project.org/2010/03/17/doctrine-performance-revisited.html

Esto es de los 1,2 docs pero creo que los consejos de hidratación se aplican en 2,0 http://doctrine.readthedocs.org/en/latest/en/manual/improving-performance.html

Otra regla importante que pertenece a esta categoría es: Sólo se ha podido recuperar objetos cuando realmente los necesitas. Doctrine tiene la capacidad de buscar "gráficos de matriz" en lugar de gráficos de objetos. A primera vista, esto puede sonar extraño, porque ¿por qué usar un mapeador relacional de objetos en primer lugar? Tómate un segundo para pensarlo. PHP es, por naturaleza, un lenguaje precedente que se ha mejorado con muchas características para un OOP decente. Las matrices siguen siendo las estructuras de datos más eficientes que puedes usar en PHP. Los objetos tienen más valor cuando se usan para lograr una lógica empresarial compleja. Es un desperdicio de recursos cuando los datos se envuelto en estructuras de objetos costosos cuando no se tiene el beneficio de que

Sobre el uso de HYDRATE_ARRAY:

¿Puede usted pensar en cualquier beneficio de tener objetos en la vista en lugar de matrices? No vas a ejecutar lógica de negocios en la vista, ¿verdad? Un parámetro que puede ahorrar una gran cantidad de procesamiento innecesaria:

$blogPosts = $q->execute(array(1), Doctrine_Core::HYDRATE_ARRAY);