Con Doctrine, ¿cuáles son los beneficios de usar DQL sobre SQL?

Question

¿Puede alguien proporcionarme un par de razones claras (basadas en hechos) para usar/aprender DQL vs. SQL cuando necesite una consulta personalizada mientras trabajo con Doctrine Classes?

Creo que si no puedo usar la funcionalidad relacional incorporada de un ORM para lograr algo, generalmente escribo un método personalizado en la clase DoctrineTable o Doctrine extendida. En este método, escriba el necesario en SQL directo (usando PDO con las declaraciones preparadas/protección de inyección adecuadas, etc.). DQL parece un lenguaje adicional para aprender/depurar/mantener que no aparece proporciona suficientes razones convincentes para usar en situaciones más comunes. DQL no parece ser mucho menos complejo que SQL para garantizar su uso; de hecho, dudo que pueda usar DQL efectivamente sin tener una comprensión sólida de SQL. La mayoría de los puertos de sintaxis SQL básicos funcionan bastante bien en los DB más comunes que usará con PHP.

¿Qué me estoy perdiendo/pasando por alto? Estoy seguro de que hay una razón, pero me gustaría saber de las personas que intencionalmente la han usado de manera significativa y de qué fue la ganancia al tratar de trabajar con SQL simple.

No estoy buscando un argumento que apoye ORMs, solo DQL cuando necesite hacer algo fuera del núcleo tipo 'get-by-relationship' needs, en una configuración LAMP tradicional (usando mysql, postgres, etc ...)

Answer 1

Para ser honesto, aprendí SQL usando Doctrine1.2 :) Ni siquiera estaba al tanto de las teclas foráneas, operaciones en cascada, funciones complejas como group_concat y muchas, muchas otras cosas. La búsqueda indexada también es algo muy bueno y útil que simplemente funciona desde el primer momento.

DQL es mucho más simple de escribir y entender el código. Por ejemplo, la siguiente consulta:

$query = ..... // some query for Categories 
    ->leftJoin("c.Products p") 

lo hará la izquierda de combinación entre las categorías y los productos y no tener que escribir EN p.category_id = c.id.

Y si en el futuro cambia la relación de uno-2-muchos, digamos many-2-many, esta misma consulta funcionará sin ningún cambio. Doctrine se encargará de eso. Si hiciera eso usando SQL, entonces todas las consultas tendrían que ser cambiadas para incluir esa tabla intermediaria many-2-many.

Answer 2

Encuentro DQL más legible y práctico. Si lo configura correctamente, será más fácil unir objetos y las consultas serán más fáciles de escribir.

Su código será fácil de migrar a cualquier RDBMS.

Y lo más importante, DQL es el lenguaje de consulta de objeto para su modelo de objeto, no para su esquema relacional.

Answer 3

El uso de DQL te ayuda a manejar Objetos. en el caso de la inserción en databae, se inserta un objeto

$test = new Test(); 
$test->attr = 'test'; 
$test->save(); 

en el caso de la selección de databae, tendrá que elegir una matriz y luego se puede llenar en su objeto

public function getTestParam($testParam) 
    { 
     $q=Doctrine_Query::create() 
       ->select('t.test_id , t.attr') 
       ->from('Test t ') 
      $p = $q->execute(); 
      return $p; 
    } 

se puede comprobar Doctrine Documentation para más detalles

Answer 4

La respuesta de Zeljko es bastante acertada.

Motivo más importante para ir con DQL en lugar de SQL sin procesar (en mi libro): Doctrine separa la entidad de la forma en que persiste en la base de datos, lo que significa que las entidades no deberían tener que cambiar como cambios de almacenamiento subyacentes. Eso, a su vez, significa que si alguna vez desea hacer cambios en el almacenamiento subyacente (es decir, cambiar el nombre de las columnas, alterar las relaciones), no tiene que tocar su DQL, porque en DQL utiliza las propiedades de la entidad en su lugar (que solo le sucede a traducirse entre bastidores para corregir SQL, según tus asignaciones actuales).