Newsgroup: it.lavoro.informatica
Titolo: aiuto 3000 queries in un colpo solo!

Mi hanno affibbiato un lavoro che consiste nel ristrutturare 
un sito in php...
Fatto sta che nella parte gestionale scopro con sommo orrore 
che una pagina web a cui accedono solitamente circa 4 utenti 
contemporaneamente, genera queries a valanga circa 3000/3500 
ogni volta che la si apre!
La cosa piu' triste e' che se gli utenti aumentano dei 
record in altre parti del programma le queries in quel punto 
aumentano proporzionalmente! :(
Ora mi ritrovo con alcune domande interiori:
1.Come' possibile che accadano queste disgrazie?
2.Ora io che avevo richiesto x euro per ristrutturare la 
parte php... ora cosa faccio gli chiedo piu' soldi per 
rifare anche il database?
3.Ottimizzando il tutto sono arrivato a fargli fare 700 
query :( di meno di cosi' non c'e' la faccio dovrei 
ricorrere ad ajax che gli avevo espressamente detto che non 
intendevo utilizzare.
4.sono tentato di lasciargli lo stesso merdaio che hanno 
oltretutto gia' con 700 queries va da dio(oddio un dio po' 
zoppo ma va)!!!!
Ciao
ps
Quei figli di mi*****tta!! mi hanno i******to mi avevano 
fornito il database non completo di tutti i dati(con la 
scusa della privacy)... infatti andava a palla con poche 
centinaia di rekords e io sono un emerito imbecille a 
fidarmi di quella gentaglia!!!
-- 
#Wizard Developer#
http://www.wizardtale.org


Certo, puoi proporglielo.

 Genera automaticamente 3500 where sulla stessa tabella? O che cosa?
il db a mio parere e' troppo razionalizzato o almeno credo 
perche' mi pare progettato bene cioe' le robe che deve avere 
le ha solo che per tirare fuori i dati bisogna fare i salti 
mortali e il programmatore che l'aveva fatto... ha creato 
dei gran cicli uno dentro l'altro senza fare query 
complesse... ho provato a moddare le query e sono arrivato a 
fargli fare 700 query ma meno di cosi' non ce la faccio(poi 
oggi mi veniva da sboccare che e' una cosa che odio, in 
quanto la base dati non l'ho fatta io)... domani vedo di 
riuscir far piu' roba possibile lato server, ma ke kakkio.

 emerito imbecille a fidarmi di quella gentaglia!!!
Quando faccio un contratto di fornitura io lo faccio sempre 'allo stato
attuale delle cose'; metto subito in chiaro che se vengono modificate
le specifiche o se vengo a scoprire cose che mi vangono taciute, il
cliente non puo' nascondersi dietro 'ma sei tu il programmatore', a
meno che non sia stata mia responsabilità, dietro compenso, l'analisi
della situazione reale su cui si basa il mio preventivo.
Nel tuo caso, innanzi tutto si potrebbe dire che la parte PHP esula
dall'accesso ai dati (stiracchiata, ma ci sta). Debbo peraltro pensare,
visto il numero di queries, che chi l'ha pensato in origine non fosse
molto ferrato nell'accesso alle basi dati (Dio volendo chiamare Access
una base dati). Poi, si potrebbe fare riferimento alla tua
impossibilità di un'analisi corretta, visto che ciò che ti è stato
fornito non corrisponde alla realtà.
Unico problema, secondo me, che le cose avrebbero dovuto essere chiare
fin da subito.
-- 
Ciao!
Luca

 mancanza di determinati record? 
Se è progettato come temo (e come a occhio temi anche tu) avere 100
anagrafiche o averne 100.000 fa una bella differenza.
-- 
Ciao!
Luca

 complesse...
Fare la join "a mano" dentro un programma può essere talvolta una
soluzione
valida per trasferire carico elaborativo fuori dal dbms, magari
quando
va fatta solo per una parte delle righe.
Certo i dbms sono (o dovrebbero) essere ottimizzati per questi tipi
di operazioni. Ma penso a dbms potenti, Sql Server, Oracle, DB2.
"Progettato bene" significa che probabilmente è stato normalizzato
a fondo con un bel pò di tabelle, che vanno quasi sempre interrogate
in join. Evidentemente programmatore e progettista db non si
conoscevano,
ognuno ha fatto come gli pareva e gli veniva meglio.... :-)

 conoscevano,
yeah, deve essere successo cosi'... con l'aggiunta che il 
cliente gli aveva fatto delle richieste "strane" in quella 
pagina c'e' il mondo! :)
Ciao

 Fai le cose bene. Non strafare ma non fare nemmeno il menefreghista.
innerjoinando di qua , innerjoinando di la' e utilizzando il 
detersivo per il bucato(che oltretutto non conosco bene e 
volevo evitarlo come la peste) sono arrivato a 40 queries
(da ~3180!!!!!!!!!!!!!!!!!!!!!)... ora mi sono scassato i 
marones e mi fermo...
Ma che cappero aveva nella testa quello che l'aveva fatto! :(
*tristezza:*
C'era un numero(a seconda di quante settimane erano state 
impostate) di <select> dipendenti, quest'ultime a seconda 
della select padre avevano gia' i dati caricati a priori 
tramite tonnellate di javascript(ma chi ha inventato quello 
skifo di linguaggio) creato dinamicamente con una vagonata 
di sql e cicli(e solo qua gia' si formavano un migliaio di 
query).
Non  ho parole! -_-
Sciao

 conosco bene e volevo evitarlo come la peste)
...qui proprio non ho capito a che ti riferisci...
Massimo

 intendevo utilizzare.
in che modo con ajax penseresti di ridurre il numero delle query?
forse è la strada giusta lo stesso, ajax o non ajax.

 ...qui proprio non ho capito a che ti riferisci...
mi riferivo ad ajax...
quei cavoli di turni sono dipendenti dai corsi che a loro 
volta dipendono dalle settimane(cosi' e' la base dati)... 
per riuscire a fare una sintesi del world in unico tabellone 
il programmatore puo' scegliere svariate soluzioni:
1. il diavolo (mega accrocco di dio via codice)
2. l'acqua santa (trovare una soluzione elegante)
3. uccidere le persone(i clienti) che vogliono quello 		 
stramaledetto tabellone.
4. suicidarsi
5. digitare "emerge -e world" dal prompt ms'dos e vedere che 
     	succede :)
Coloro che credono nel male invertano i contenuti nelle 
parentesi dei relativo punti 1 e 2.
Aiuto ho perso tutti i neuroni... d'ho!
Allora a mio parere o il programmatore si precaricava tutte 
le possibilita', accroccando il tutto con javascript per 
dargli una parvenza di dinamicita' :) generando array 
bidimensionali ma che dico tridimensionali ma che dico 
quadridimensionali e legando il tutto con eventi sulle tre 
combobox...
Oppure poteva utilizzare semplicemente l'oggetto XMLHttp 
nella suo metodo piu' volgare del responseText per caricare 
*solo* i dati che *servono* e *solo* quando servono.
Odiando javascript e non avendo mai avuto necessita' di 
implementare ajax, non l'ho mai utilizzato(sapevo come 
funziona teoricamente) e non avevo intenzione di imparare ad 
utilizzarlo... purtroppo lo usato e devo dire che e' 
semplice e a volte utile.
Ciao

 forse è la strada giusta lo stesso, ajax o non ajax.
ho spiegato nell'altro post...
ps
Ke Kakkio insegnano alle uni di ing. informatica!?? :( :(
Nel codice vecchio tra i commenti vi e' anche l'email con 
password(-_-) del programmatore e si spaccia come ingegnere 
info.

 di sql e cicli
Tra l'altro ogni select creata dinamicamente rallenta il db, dovendo
essere interpretata dal db stesso. Quindi volendo fare vagonate
di roba dinamica bisognerebbe usare stored procedures
(disponibili in tutti i db a parte Access).
Sto programmatore è veramente uno spalasql, che veniva dalla
montagna più depressa! E poi dice che gli informatici li pagano
male...........


E direi di si! Anche non usando ajax ma ricaricando la pagina
alla vecchia maniera!

 male...........
si ma da quanto mi avevano detto che doveva fare il lavoro 
in un mese e probabilmente se ci metteva di piu' non avrebbe 
preso i soldi... e pero' ca***0!!

 preso i soldi...
Vedi che veniva da zona depressa, in cui l'SQL è sconosciuto,
 e non poteva rinunciare a quei 4 soldi :-)

 }
A giudicare dai commenti fatti usando "//", direi che si tratta di C++,
ma in questo caso ti ricordo che usare la #define non e` consigliabile.
;)
-- 
Salvatore Iovene
http://www.iovene.com/
"A world without hackers would be a world without curiosity and
innovation." - Jon Erickson