Sito dinamico: query continue o query unica iniziale?

[aschenaz]

E' un dubbio che mi sono sempre posto, con riferimento all'impiego delle risorse.
In questa fase, magari, non consideriamo limiti di query, banda etc. eventualmente
posti dall'hosting...

Avendo un sito totalmente o parzialmente dinamico (naturalmente parliamo di
database non monumentali), è preferibile:
- ricorrere al db con query diverse nel momento in cui serve?
- formulare una query unica iniziale, popolando magari un array multidimensionale
con tutto (o quasi) il db e poi richiamare al bisogno tale array?

Non mi sono mai messo a studiare il codice dei vari cms: sarebbe interessante
constatare come sono strutturati a tale proposito...

[conraid]

E' un dubbio che mi sono sempre posto, con riferimento all'impiego delle risorse.
In questa fase, magari, non consideriamo limiti di query, banda etc. eventualmente
posti dall'hosting...

Avendo un sito totalmente o parzialmente dinamico (naturalmente parliamo di
database non monumentali), è preferibile:
- ricorrere al db con query diverse nel momento in cui serve?
- formulare una query unica iniziale, popolando magari un array multidimensionale
con tutto (o quasi) il db e poi richiamare al bisogno tale array?

Non mi sono mai messo a studiare il codice dei vari cms: sarebbe interessante
constatare come sono strutturati a tale proposito...

Il problema è "come lo richiami quell'array?"
nel senso che non puoi passare variabili tra i vari script se non con GET o POST, e quindi a meno che non fai un unico gigantesco script o passare tutto il db con tali variabili, è preferibile fare varie query al momento del bisogno e dividere i vari file
anche perché una query ottimizzata e limitata consuma meno risorse e ci sta meno tempo di una grande query, e se una persona non accede mai a quella parte di script perché mettere in memoria tutto quanto?
o ho capito male la questione?

[aschenaz]

No, hai capito benissimo.

Il mio dubbio riguardava il fatto che non mi sembra molto salutare per le risorse
fare 100 query diverse nell'ambito della stessa pagina e pensavo che magari fosse
preferibile popolare l'array (fruendo di "show tables" e quindi strutturandolo
gerarchicamente e convertendo le varie relazioni...) e poi richiamarlo, ad esempio,
con $tabelle["pagina"]["tabella"]["etc"]...

Il popolamento dell'array potrebbe ad esempio andare nel costruttore dell'eventuale
classe (in effetti qualche test l'ho fatto e per funzionare funziona...).

Ma già mi rendo conto da solo è un'idea un po' folle...

[conraid]

No, hai capito benissimo.

Il mio dubbio riguardava il fatto che non mi sembra molto salutare per le risorse
fare 100 query diverse nell'ambito della stessa pagina e pensavo che magari fosse
preferibile popolare l'array (fruendo di "show tables" e quindi strutturandolo
gerarchicamente e convertendo le varie relazioni...) e poi richiamarlo, ad esempio,
con $tabelle["pagina"]["tabella"]["etc"]...

Il popolamento dell'array potrebbe ad esempio andare nel costruttore dell'eventuale
classe (in effetti qualche test l'ho fatto e per funzionare funziona...).

Ma già mi rendo conto da solo è un'idea un po' folle...

Una cosa è una tabella che viene richiamata varie volte nello stesso script (inteso come singolo file php), altro è una tabella che viene richiamata da script diversi, anche se facenti parte della stessa applicazione, o in determinate condizioni.
Mi spiego

se ho

connetti al db
query1 al db (select di dati1)
varie cose
query2 al db (select di dati2)
varie cose
query3 al db (select di dati3)
varie cose
query4 al db (select di dati4)

allora potrebbe anche funzionare, ma se ho

connetti al db
query1 al db (select di dati1)
varie cose
se condizione query1 allora
query2 al db (select di dati2)
altrimenti
query3 al db (select di dati3)
altrimentiancora
query4 al db (select di dati4)

inizia ad avere meno senso, in quanto fai query diverse a seconda di cosa restituisce query1

ancora meno senso se

connetti al db
query1 al db (select di dati1)
richiamo script2 che fa altre query

anche fare un costruttore che popola l'array eviti il passaggio di variabili, ma per ogni chiamata alla classe fai una grande query?
ripeto, a meno di situazioni particolari non mi piace

[masalapianta]

(<premessa>parto dal presupposto che tu utilizzi php+mysql</premessa>) se nell'ambito del medesimo script hai piu' query diverse (ovvio che se ti servono i medesimi dati in piu' punti dello script non farai n volte la stessa query ma riutilizzerai sempre la stessa) da fare, e' indifferente farle tutte insieme o una per volta, a condizione che tu faccia una sola connect al db (ovvio che se per ogni query fai una connect, la query,la close e via da capo, e' piu' oneroso) per tutte le query; se invece intendi caricare in ram il db e utilizzarlo da vari script in chiamate diverse, allora la situazione e' piu' complessa; devi avere un application server che ti permetta di avere delle variabili globali accedibili da ogni script in chiamate diverse (ma questo, che io sappia, con il dso di php su apache non e' possibile; forse qualcosa si puo' fare con fastcgi ma non ne son sicuro) come ad esempio con mod_perl; quindi se usi php su apache, e vuoi fare una cosa del genere, le soluzioni meno peggio sono o usare la shared memory (non te lo consiglio) oppure vai di memcached (che tra le altre cose permette anche un approccio distribuito al caching).

N.B. ho dato per scontato che tu non volessi utilizzare la query cache nativa di mysql

[aschenaz]

Effettivamente il cosiddetto "popolamento" avverrebbe ad ogni istanza
della classe e, in pratica, ad ogni accesso, cambio pagina, refresh...
Inoltre, un db nato snello è giocoforza destinato a ingrandirsi e con
l'andare del tempo i "presunti" vantaggi (qualora effettivamente ci fossero)
sparirebbero inesorabilmente.

Nulla, è un'idea sbagliata. Meglio razionalizzare le query (naturalmente
la connessione viene effettuata solo all'inizio) e, magari, ricorrerere
alla dinamicità solo quando sia effettivamente necessaria (se si prevede
che una pagina possa cambiare una volta l'anno, ad esempio, meglio
tenerla statica, no?).

Grazie 1000 ad entrambi.

N.B. ho dato per scontato che tu non volessi utilizzare la query cache nativa di mysql

Hai pensato bene: infatti ne sento parlare ora per la prima volta.
Di fatto, il mio utilizzo di MySQL è veramente limitato (mi accontento
delle query più semplici, elaborando poi magari i dati col php...).

[conraid]

N.B. ho dato per scontato che tu non volessi utilizzare la query cache nativa di mysql

Hai pensato bene: infatti ne sento parlare ora per la prima volta.
Di fatto, il mio utilizzo di MySQL è veramente limitato (mi accontento
delle query più semplici, elaborando poi magari i dati col php...).

la query_cache di mysql si attiva da sola

In mysql 4 se non sbaglio va impostata una variabile che indica la tipologia, disattivata, automatica e manuale.
Se è impostato per invocare manualmente la cache, devi fare una query apposita
SELECT utente FROM slacky WHERE name="conraid"
diventa
SELECT SQL_CACHE utente FROM slacky WHERE name="conraid"

In mysql 5 invece non esiste questa tipologia (è attiva di default) e per disabilitarla devi impostare la grandezza della cache a 0 o usare SQL_NO_CACHE

Potrei anche aver detto castronerie, comunque
http://dev.mysql.com/doc/refman/5.0/en/query-cache.html

[masalapianta]

In mysql 5 invece non esiste questa tipologia (è attiva di default) e per disabilitarla devi impostare la grandezza della cache a 0 o usare SQL_NO_CACHE

ni (merge tra no e si ), la query cache e' attiva di default, ma non basta quello (non usare SQL_NO_CACHE) per renderla attiva realmente, bisogna anche impostare la variabile "query_cache_size" (la quantita' massima di ram da allocare per la cache) ad un valore diverso da zero, che e' il default, quindi la query_cache e' disattiva per default; poi ovviamente non basta solo attivarla, ci vuole del sano tuning sulle varie variabili query_cache_$x per trovare la configurazione piu' performante con il proprio ambiente

[masalapianta]

Effettivamente il cosiddetto "popolamento" avverrebbe ad ogni istanza
della classe e, in pratica, ad ogni accesso, cambio pagina, refresh...

ripeto, per ovviare a questo problema (che si ha con il dso di php su apache), c'e' piu' d'un sistema (memcached, shared memory, fastcgi(forse) e la query_cache di mysql)

Inoltre, un db nato snello è giocoforza destinato a ingrandirsi e con
l'andare del tempo i "presunti" vantaggi (qualora effettivamente ci fossero)
sparirebbero inesorabilmente.

non necessariamente, anche con un db grande e una cache piu' piccola, opportune politiche di caching portano comunque grossi vantaggi

Nulla, è un'idea sbagliata.

no, il caching e' un'ottima idea, basta solo tener presente i dettagli dell'architettura cui applicarla in modo da poter scegliere la soluzione migliore

Meglio razionalizzare le query

quello va fatto sempre a prescindere dal caching; a tal proposito e' d'obbligo dare una letta a questo:
http://dev.mysql.com/doc/refman/5.1/en/ ... ation.html

[aschenaz]

ripeto, per ovviare a questo problema (che si ha con il dso di php su apache), c'e' piu' d'un sistema (memcached, shared memory, fastcgi(forse) e la query_cache di mysql)

Diciamo che il mio interesse era più che altro "ipotetico" e che i siti dinamici che
allestisco io non dovrebbero esigere tali soluzioni, che, a quanto pare, sono
consigliabili per database ad alto traffico (specie in lettura). Infatti, per esempio:

If you have a high-traffic site that is dynamically generated with a high database load that contains mostly read threads then memcached can help lighten the load on your database.

Oltretutto, bisogna vedere cosa ne pensa l'hosting...

no, il caching e' un'ottima idea, basta solo tener presente i dettagli dell'architettura cui applicarla in modo da poter scegliere la soluzione migliore

Beh, almeno mi consolo con il fatto che l'idea di base non era sbagliata...

Meglio razionalizzare le query
...
quello va fatto sempre a prescindere dal caching; a tal proposito e' d'obbligo dare una letta a questo:
http://dev.mysql.com/doc/refman/5.1/en/ ... ation.html

Ottimo: è arrivato il momento di rimettersi a studiare!

Grazie ancora.