Newsgroup: it.comp.www.php
Titolo: PHP o MySql

Buongiorno,
sto cercando capire se conviene caricare più PHP o MySql. Mi spiego meglio...
MySql ha molte funzioni, sia per intervenire sulle stringhe (concatenare, togliere spazzi...) sia per lavorare con i numeri e le date. Ma queste operazioni dove è più performante farle? Farle eseguire da MySql durante la query? O è meglio prendere i dati più grezzi possibile e poi elaborare il tutto con PHP?


Dipende da troppi fattori.
 
Se non hai il DB sulla stessa macchina dove gira PHP, la cosa migliore e` 
far passare meno dati possibile dal DB a PHP, perche` la rete e` il collo 
di bottiglia maggiore.
 
Le query vanno compilate dal DB di volta in volta, quindi a meno che non 
definisci delle stored procedures o delle view (quindi precompilate sul 
server) il tempo di parsing della query potrebbe essere piu` alto di 
quello dell'elaborazione.
 
In PHP hai generalmente molta piu` flessibilita`, quindi alcune 
operazioni difficilmente le potrai delegare al DB.
 
E, per finire, il tutto ha senso se parliamo di decine di migliaia di 
elementi da elaborare. Se stiamo parlando di 100 elementi la differenza 
e' talmente minima che non e` nemmeno misurabile in modo affidabile.
 
Bye.
 


In genere le operazioni di query è meglio vengano svolte da MySQL.
Per quanto riguarda la manipolazione di stringhe o numeri, secondo me 
puoi anche usare MySQL, ma forse PHP ti dà un controllo migliore.
 
Tutto questo IMHO.


La prima che hai detto.


Di solito buttare parte della logica dentro le query aiuta a separare 
meglio il codice, ma non è sempre vero
Per ottimizzare l'uso di MySQL usa la SQL_CACHE e i prepared statements
Per vedere grandi vantaggi o hai carichi mostruosi o hai scritto davvero 
male
 
Per avere la (quasi) certezza che il db venga usato bene usa una 
libreria ORM che ti isola in modo stupendo dall'sql
 
M
 
-- 
I fatti mi cosano


Vedo che ognuno mi dice una cosa diversa, tra chi dice che è meglio delegare a php in quanto più flessibile e chi dice meglio MySql :P
Dove starà la verità?


Ho visto che mi chiedevi su gmail, ma rispondo qui che magari interessa 
anche altri
Per cose piccole ho usato redbean per cose più grosse ho usato Doctrine2
Ce n'è tante cmq e sceglierne una adatta ai tuoi scopi è questione di gusti.
Sicuramente non sono efficienti al 100%, ma di solito incorporano più 
know-how specifico di quanto mediamente se ne abbia come singoli 
sviluppatori
Inoltre ti permette di isolare meglio il tuo codice dall'sql
Io sono un grande fan delle librerie ORM se non si fosse capito :)


 grande fan delle librerie ORM se non si fosse capito :) M
 
Io, che sono un anti-fan degli ORM, do` anche il parere opposto. :)
 
Non ha senso, secondo me, "forzare" una struttura a oggetti in una 
relazionale. Un ORM astrae troppo dall'SQL che ci sta sotto, e molto 
spesso impone limitazioni molto pesanti su quello che puoi fare. Oltre a 
renderti oscura la struttura delle tabelle.
 
Preferisco di gran lunga sistemi come PDO (che e` un minuscolo layer di 
astrazione, che ti semplifica le cose normali ma ti consente anche di 
fare quelle complesse) o al massimo un TDG (Table Data Gateway) come 
quello implementato in Zend Framework, che mappa 1:1 una tabella a un 
oggetto.
 
Bye.
 


Libreria ORM tipo?


PDO per php potrebbe essere mysqli ?


In medio stat virtus...
 
Se hai una tabella da 100 milioni di righe di fatture e devi 
intersecarla con l'anagrafica per avere un elenco di fornitori del 2011, 
è meglio che l'operazione sia tutta interna a MySQL.
 
Se hai 100 fatture e un'anagrafica da 4 righe, puoi farlo direttamente 
con PHP.
 
La risposta giusta è "dipende...".
 

 PDO per php potrebbe essere mysqli ?
 
Mi pare che di default PDO usi mysqli "dietro le quinte".
 
Ma sono due cose separate. Puoi anche usare mysqli senza PDO. :)
 
Bye.
 
 


Assolutamente d'accordo sugli svantaggi di un ORM, tutto sta a vedere se 
per i propri scopi gli svantaggi vengono compensati dai vantaggi.
C'è da dire che quasi tutti gli ORM alla fine propongono una propria 
versione di SQL ed eventualmente la possibilità di passare ad SQL "crudo"
La struttura delle tabelle rimane oscura perché _teoricamente_ 
basterebbe cambiare un parametro di config per usare un RDBMS diverso a 
piacere fra quelli supportati dalla libreria ORM. Poi di fatto non è 
spesso così semplice


 MySql ha molte funzioni, sia per intervenire sulle stringhe (concatenare, togliere spazzi...) sia per lavorare con i numeri e le date. Ma queste operazioni dove è più performante farle? Farle eseguire da MySql durante la query? O è meglio prendere i dati più grezzi possibile e poi elaborare il tutto con PHP?
 
Io lavoravo così negli anni '80 con DB3.
 
Poi per fortuna si sono affermati i RDBMS client-server e il linguaggio SQL.
 
Tornare agli anni '80 mi sembra un'idiozia. Se hai un RDBMS
client-server fai fare a lui tutto il lavoro che è in grado di fare.
 
Altrimenti tanto vale memorizzare i dati in file di testo.
 
	Y.

Il 12/04/2012 09:02, Matiux ha scritto:

E' una domanda spinosa, perchè una parte è rispondibile in modo 
piuttosto oggettivo, un'altra parte è veramente molto soggettiva.
Far fare al db i lavori tipicamente pesanti è abbastanza logico, usarlo 
per altre cose (come un upper()) è + soggettivo.
La mia impostazione attuale, maturata negli anni, è di spostare ogni 
cosa possibile sul db, mantenere le query nei dao il + snelle possibili 
e fare tutta l'aggregazione su viste (sottlineo però che questo ha senso 
se usi un rmdb che mantiene gli indici sulle viste (o ancora meglio se 
ha le viste materializzate), sennò prestazionalmente è una soluzione 
orrenda). Non rivendico il fatto che sia la scelta migliore, ma 
sicuramente è quella in cui mi trovo meglio, contando anche che se con 
php cambiare un dao e rideployarlo è quasi sempre banale, con magari 
java è meno agevole; quindi poter agire su un a vista senza toccare il 
codice mi è molto spesso comodissimo in fase di manutenzione.
 
Anche io non sono un fan degli orm (ne un hater cmq), ma la soluzione 
con cui mi trovo meglio è quella basta su TDG (io uso quello di 
codeigniter, ma penso siano tutto molto simili).
 
La mia impostazione è molto estrema, ho colleghi che mi dicono 
scherzosamente che ormai faccio applicazioni in sql, ho vecchi capi che 
reputano malissimo spostare la logica dentro al db perchè non puoi 
mettere commenti nelle viste (o usare un svn) e diventa + complesso 
l'aspetto cooperativo; però di nuovo, dopo aver provato un po' di tutto 
questo è il sistema con cui io mi trovo meglio, e penso che sia sempre 
una cosa importante, senza stare ad inseguire per forza un dogma, che 
spesso non esiste.
 
-- 
Z.

 spesso non esiste.
 
+1
 
Senza dire che spostando la logica nel db, si lascia all'applicazione
web il solo compito di manipolare i dati in output dal db per il
rendering su pagina: che č proprio quello il lavoro che deve fare.
E senza dire che... spostando la logica nel db, lato applicazione ti
trovi a fare una semplice {call myStoredProcedure(?,?)} che č
portabilissima: in pratica se in un futuro cambi architettura db ti
basta realizzare la stessa stored e lato applicazione web (oltre che ai
driver) non devi cambiare nulla. Io ho fatto cosě e ho un'applicazione
che gira in modo trasparente su Oracle, MySQL e MS SQL Server 2008(*).
 
(*) Di contro ti troverai a dover sviluppare in qualche modo la stessa
stored in modo che funzioni su ogni architettura db...
 
 
M.

 che gira in modo trasparente su Oracle, MySQL e MS SQL Server 2008(*).
 
Questo e` piu` semplice ancora se lasci la logica fuori fuori dal db e 
usi l'sql piu` standard che ci sia: cambi il driver e non devi neppure 
riscrivere le stored (e in teoria nemmeno le query, che poi non sia 
cosi` facile come sulla carta, purtroppo, e` altro par di maniche).
 
-- 
 

 cosi` facile come sulla carta, purtroppo, e` altro par di maniche).
 
Scrivere query indipendenti dal database oltre un certo grado di
complessità è impossibile, a meno di non volere scrivere query con
performance disastrose.
 
Il difficile è spiegare al cliente che paga migliaia di euri per la
licenza Oracle che sì, effettivamente le performance sono penose, però
l'applicazione è indipendente dal database e può girare tal quale anche
su SQLServer (che il cliente non ha e non vuole vedere nemmeno in
cartolina).
 
L'indipendenza dal database non è necessariamente un bene, anzi quasi
mai lo è.
 
	Y.