Drupal query

[Uno]

Ma è vero che una installazione normale di Drupal, con qualche blocco configurato arriva come niente alle 200 query e a salire?
Io l'ho testato parecchio tempo fa e non l'ho messo in debug quindi non ho idea, l'ho letto...ed è pur vero il numero conta fino ad un certo punto se comunque queste occupano poco "spazio", ma mi pare proprio tanto.

[guest]

Ma, guarda, non conosco Drupal, ma una delle nostre recenti applicazioni fa un massiccio uso di ORM per l'accesso ai database ed andare su con le query è un gioco da ragazzi, sopratutto se devi fare molti check di validità e verificare le transazioni.

Più che preoccuparsi del numero di query, mi preoccuperei della struttura database, dei suoi indici e di come sono strutturate le query stesse.

Se devi fare, ad esempio, 300 "SELECT id" usando un where fatto su un indice, avranno un impatto quasi nullo sul server, mentre invece una singola query fatta male o una JOIN farlocca ti ammazza tutto.

[andrea.paiola]

a parte che è appena uscito drupal 7 percui se vuoi testare quello fallo pure (anzi se gli riporti i risultati gli fai solo un piacere), ne basta una fatta male su una pagina un po' visitata e non cachata per sdraiarti il server

sui blocchi hanno aggiunto la cache nell'ultima versione, comunque (cache sempre su db)

col modulo Devel puoi vedere che query fa

[Uno]

A dire il vero mi interessa poco Drupal, era però la scusa e l'occasione per paragonare il mio modo di programmare a realtà che hanno nel bene o nel male trovato un ampio spazio a livello mondiale.
Io "mi faccio dei problemi" se supero la decina di query pur rimanendo assolutamente in poche decine e poi leggo di 2/300....
E' vero, e sono il primo a dirlo, che una può valere per 50, ma mi viene proprio difficile pensare a come su una singola pagina riescano a fare 300 query.

[andrea.paiola]

ogni modulo aggiunge per forza di cose le sue query (anche per i permessi, ricordati che di default Drupal ha una gestione dei permessi a livello di modulo), non ci vuole molto

inoltre ci sono dei moduli, penso per esempio a Views, che sono in pratica dei motori di generazione di estrazione dati e quindi di query

guardati i moduli più usati, che sono Views e CCK (che serve ad aggiungere campi)

Modules | drupal.org

sono moduli corposi, una quantità elevata di codice, e fanno molte query perchè devono fare operazioni complesse a livello proprio di dati

praticamente tutto cachabile (sempre su db)

[guest]

E' vero, e sono il primo a dirlo, che una può valere per 50, ma mi viene proprio difficile pensare a come su una singola pagina riescano a fare 300 query.

Se usi qualche sistema ORM o una sorta di ActiveRecord, vien spontaneo eseguire vagonate di query, di piccolissima entità.

In certe condizioni, molto meglio 2 query singole su due tabelle che una join, pertanto a meno che l'ORM non sia molto evoluto, tendi a creare due oggetti, uno per la tabella1, uno per la tabella2, a fare due select secche e poi elaborare nel model a livello di PHP.

Anche a livello di leggibilità del codice, spesso due query distinte elaborate a livello di php sono migliori, eviteresti di dover configurare (sempre tramite php) vagonate di relazioni e di dover configurare tutti i model, uno per uno.

Se, ad esempio, sviluppi un web service restful, avrai una query per l'autenticazione che ti ritorna un oggetto User.
Poi dovrai verificare se la risorsa richiamata è accessibile da tale user, quindi avrai una seconda query secca che ritorna, probabilmente, un singolo record in caso di OK (a meno che tu non voglia prendere, ad ogni richiesta, anche tutta la struttura di permessi, cosa non molto sensata).
La risorsa è accessibile e l'utente sta cercando di caricare un prodotto dalla tabella Products. Altra query.
Quando esegui l'operazione, vuoi inviare una notifica al parent del tuo utente, quindi fai una ulteriore query, nuovamente sulla tabella Users, che ti ritornerà un oggetto Padre.
Sei già a 4 per aver fatto una operazione che sulla carta corrisponderebbe ad una singola select su un prodotto.

Se poi devi fare un ordine, avrai tutte le query di cui sopra, più una che verifica la disponibilità del prodotto e se disponibile lo ordina. Ecco che ne aggiungerai altre 2.

EDIT: dimenticavo: mysql gestisce benissimo centinaia di migliaia di query contemporanee, se poi sono piccole ed il db è fatto bene, staranno tutte in cache quindi eseguire una query o eseguirne 500 non campia niente. Discorso diverso se inizia a creare tabelle con cambi BLOB/TEXT o altre tipologie non cachabili, ma in tal caso il problema è il database, non il codice php che fa molte interrogazioni.

[andrea.paiola]

Se usi qualche sistema ORM o una sorta di ActiveRecord, vien spontaneo eseguire vagonate di query, di piccolissima entità.

Drupal ha un'astrazione del database, ma non ha un ORM (anzi, non è manco programmato ad oggetti PHP)
Database abstraction layer | Drupal API

con Drupal 7 è diventato "agnostico"
Database API | drupal.org

esempi di queries, così almeno è chiaro di cosa stiamo parlando
Static queries | drupal.org

[guest]

esempi di queries, così almeno è chiaro di cosa stiamo parlando
Static queries | drupal.org

Quelle query li, con gli indici ben fatti, sono "inesistenti" a livello di server.

[andrea.paiola]

se volete disquisiamo della struttura del database di Drupal (e della sua ottimizzazione) con installati i moduli più usati

[guest]

se volete disquisiamo della struttura del database di Drupal (e della sua ottimizzazione) con installati i moduli più usati

Ma anche no

[Uno]

se volete disquisiamo della struttura del database di Drupal (e della sua ottimizzazione) con installati i moduli più usati

A me interesserebbe pure, però non potrei contribuire inizialmente perchè non ho il tempo di prenderlo in mano. Se qualcuno che lo conosce impostasse il discorso poi interverrei.

[andrea.paiola]

ho preso Drupal 7, ci ho installato un po' tra i moduli più usati e li ho attivati

ho preso un po' di temi tra i più usati e li ho attivati, ho messo come default zentropy, che al momento mi piace come starter theme

tramite il modulo devel posso inserire contenuti fake e vedere che query fa...

ho aperto un po' di nodi a caso (senza cache particolari) e ho visto che la query più pesante che fa è sempre drupal_write_record | Drupal API e impiega tra i 2 e i 6 ms qui in locale (sono win 7 e ho installato wamp)

forse viene eseguita perchè sono loggato come amministratore, questa non vuole essere un'analisi fatta per bene, eh sia chiaro

aggiungo anche 2 info prese dal modulo devel su un nodo a caso
Executed 66 queries in 22.02 ms. Queries exceeding 5 ms are highlighted. Memory used at: devel_boot()=3.72 MB, devel_shutdown()=24.6 MB, PHP peak=26.75 MB.

[andrea.paiola]

non parla proprio delle query, mi ero perso questa chicca e ve la voglio segnalare Drupal 7 - faster than ever - The official Google Code blog

e anche questa http://civicactions.com/blog/2009/ma...ments_vs_nodes