Dato che db_select è molto più lento di db_query, perché dovrei usarlo?


Risposte:


88

Esistono 5 motivi per utilizzare SelectQuery

  • Stai creando query dinamiche con un numero variabile di condizioni, join, campi e così via. Vedi field_read_fields () per un esempio.

  • Vuoi usare i cosiddetti Extender . Gli extender di esempio sono PagerDefault (sostituisce pager_query () ) e TableSort (sostituisce tablesort_sql () ). Ciò consente di aggiungere ulteriori funzionalità a SelectQuery. Vedi anche Come si creano tabelle ordinabili con un cercapersone con i dati di una tabella personalizzata? . Un esempio: node_page_default () .

  • Desideri consentire ad altri moduli di modificare le tue query. Quindi è possibile aggiungere i cosiddetti tag e SelectQuery chiamerà automaticamente un hook alter corrispondente per quel tag. Sto facendo molto affidamento su questo con il mio modulo Privatemsg (lo abbiamo già fatto in D6 con un generatore di query personalizzato).

  • Se si desidera / è necessario utilizzare il sistema node_access per mostrare solo nodi che l'utente può vedere. Aggiungi il tag 'node_access' alla tua $ query. Questo sostituisce db_rewrite_sql ().

  • SelectQuery ha alcune funzionalità che aiutano a far funzionare lo stesso codice su tutti i database supportati. Ad esempio c'è SelectQuery :: orderRandom () . E se hai una condizione LIKE, -> condition ('field', $ value, 'LIKE') farà in modo che sia sempre un confronto senza distinzione tra maiuscole e minuscole. In D6, dovevi usare LOWER () per quello che era molto più lento. Ma AFAIK, non ci sono più di questi due in questo momento.

Se nessuno di questi motivi si applica per un caso specifico, utilizzare db_query ().


1
Aggiunto un quinto punto, funzionalità di portabilità del database come orderRandom () e LIKE insensibile al maiuscolo / minuscolo.
Berdir,

6
Come sesto motivo, aggiungerei la compatibilità tra database. Le query Oracle, ad esempio, hanno una sintassi che differisce in qualche modo da MySQL, Postgres ecc. È molto più facile scrivere codice per generare la sintassi corretta da un db_select () rispetto a quando può essere un codice di query non molto compatibile con Oracle viene scaricato direttamente in db_query ().
BrianV,

9

La documentazione sudb_query() dice:

Utilizzare questa funzione per le query SELECT se è solo una semplice stringa di query. Se il chiamante o altri moduli devono modificare la query, utilizzare invece db_select ().


Grazie, ma non è abbastanza specifico. Lascia la definizione di "stringa di query semplice" abbastanza aperta all'interpretazione. Se sto selezionando tra 4 tabelle con 6 join, è ancora una query semplice o dovrebbe essere invece eseguita con db_select ()?
Chris Cohen,

3
Non si tratta di "query semplice", ma di " stringa di query semplice " e semplice in realtà significa hardcoded e non dinamico. Vedi la mia risposta per maggiori dettagli :)
Berdir

9

Uso sempre db_select poiché preferisco la leggibilità, la manutenibilità e la compatibilità incrociata tra database rispetto a piccoli miglioramenti delle prestazioni. Inoltre, penso che i numeri forniti nel numero citato diano un'immagine sbagliata della prestazione complessiva. Stiamo parlando di una differenza di 300 microsecondi su una query che, quando restituisce più di una singola colonna, viene spesso eseguita nell'intervallo di più millisecondi. E non sarei sorpreso se ci fosse un sovraccarico solo una volta (caricamento di classe) e quindi che le differenze per una richiesta (pagina) completa sono molto inferiori.


La differenza di prestazioni non è così semplice; vedere Confronta le prestazioni db_query e db_select . In genere raccomando db_query su db_select a meno che non sia necessaria una delle funzioni speciali menzionate nella risposta di Berdir.
geerlingguy,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.