Con Doctrine quali sono i vantaggi dell'utilizzo di DQL su SQL?

Question

Qualcuno può fornirmi un paio di motivi chiari (supportati) per utilizzare/imparare DQL vs. SQL quando si ha bisogno di una query personalizzata mentre si lavora con Doctrine Classes?

Trovo che se non riesco a utilizzare la funzionalità relazionale incorporata di un ORM per ottenere qualcosa, di solito scrivo un metodo personalizzato nella classe DoctrineTable o Doctrine estesa. In questo metodo scrivi il necessario in SQL diretto (usando PDO con istruzioni preparate/protezione dell'iniezione, ecc ...). DQL sembra che una lingua addizionale per imparare/eseguire il debug/manutenere non appaia fornisca sufficienti motivi validi da usare nelle situazioni più comuni. DQL non sembra essere molto meno complesso di SQL per garantirne l'utilizzo, anzi dubito che si possa usare efficacemente DQL senza avere una solida conoscenza di SQL. La maggior parte delle porte di sintassi SQL di base è abbastanza buona tra i DB più comuni che utilizzerai con PHP.

Cosa mi sfugge/mi domando? Sono sicuro che c'è una ragione, ma mi piacerebbe sentire da persone che l'hanno intenzionalmente usato in modo significativo e che cosa il guadagno è stato sopra cercando di lavorare con SQL plain-ole.

Non sto cercando un argomento che supporti gli ORM, solo DQL quando si ha bisogno di fare qualcosa al di fuori delle esigenze di base del tipo 'get-by-relationship', in un setup LAMP tradizionale (usando mysql, postgres, ecc ...)

Answer 1

Per essere onesti, ho imparato SQL usando Doctrine1.2 :) Non ero nemmeno a conoscenza di chiavi esterne, operazioni in cascata, funzioni complesse come group_concat e molte altre cose. La ricerca indicizzata è anche una cosa molto bella e maneggevole che funziona semplicemente fuori dalla scatola.

DQL è molto più semplice da scrivere e comprendere il codice. Per esempio, la seguente interrogazione:

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

farà LEFT JOIN tra categorie e prodotti e non si deve scrivere su p.category_id = c.id.

E se in futuro si cambia relazione da uno-2-molti per dire molti-2-molti, questa stessa query funzionerà senza alcuna modifica. La dottrina si prenderà cura di questo. Se lo si farebbe utilizzando SQL, tutte le query dovrebbero essere modificate per includere quella tabella molti-2-molti intermediari.

Answer 2

Trovo DQL più leggibile e pratico. Se lo configuri correttamente, sarà più facile unire oggetti e le query saranno più facili da scrivere.

Il tuo codice sarà facile da migrare a qualsiasi RDBMS.

E, soprattutto, DQL è il linguaggio di query oggetto per il modello di oggetto, non per lo schema relazionale.

Answer 3

L'utilizzo di DQL consente di gestire gli oggetti. nel caso in cui l'inserimento in databae, si inserisce un oggetto

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

in caso di selezione da databae, è necessario selezionare un array e quindi si può riempire in oggetto

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

è possibile controllare la Documentazione di Doctrine per maggiori dettagli

Answer 4

La risposta di Zeljko è piuttosto azzeccata.

La ragione più importante per andare con DQL anziché SQL raw (nel mio libro): Doctrine separa l'entità dal modo in cui è persistente nel database, il che significa che le entità non devono cambiare come modifiche di archiviazione sottostanti. Questo, a sua volta, significa che se si desidera apportare modifiche allo storage sottostante (ovvero rinominare colonne, alterare le relazioni), non è necessario toccare il proprio DQL, poiché in DQL si utilizzano invece le proprietà dell'entità (il che avviene solo per essere tradotto dietro le quinte per correggere SQL, in base alle mappature correnti).