Originariamente inviato da k.b
Secondo me stai dando troppa importanza a dei benchmark che vogliono dire poco e niente al di la' del puro gusto dei numeri. La realta' dei fatti e' che le astrazioni delle librerie di accesso ai DB aggiungono un overhead trascurabile nell'economia totale della richiesta HTTP + esecuzione. I puri tempi di esecuzione del codice in un'applicazione PHP non sono importanti come - per esmpio - in un motore grafico di un videogioco: differenze che comunque rimangono nell'ordine dei decimi di secondo (al massimo) non sono realmente percettibili in un ambiente in cui gia' solo per connetterti a un server, inviare la richiesta, scaricare la risposta e renderizzare il tutto ci metti minimo 400ms.
e per carità, sono perfettamente d'accordo, ma il problema è che se il brower impiega 400ms a renderizzare tutto e poi la pagina impiega 2 secondi per rispondere ... evidentemente è meglio iniziare ad ottimizzare il backend
ovviamente i benchmark non sono la strada assoluta da seguire, ma li faccio camminare di pari passo insieme alla semplicità di scrittura del codice
se posso ricercare strutture alternative, che magari non sono semplici semplici come un ORM, ma sono comunque semplici in modo accettabile ma nel contempo mi forniscano performance considerevolmente superiori, perché non dovrei farlo?
un meccanismo che mi fa il mapping in automatico, basta scrivere i nomi dei campi in un modo ben preciso, per me è sufficientemente semplice, così come lo è il mio sistema di gestione dei modelli, che ormai conosco a fondo. Tranne che devo costruire elementi VERAMENTE complessi per i quali non posso utilizzare le strutture di supporto che mi sono realizzato, vado abbastanza veloce.
La differenza di tempi e comodita' di sviluppo - in un ambiente in cui le app sono quasi sempre in costante evoluzione - invece e' sostanziale. E' un po' il motivo per cui le web app si scrivono in linguaggi come PHP e non in C.
e siamo perfettamente d'accordo, ma non ho fatto altro che trovare una via di mezzo tra i tempi di esecuzione e la comodità di sviluppo
indubbiamente utilizzare un ORM di terze parti si butta esclusivamente sulla comodità di sviluppo, io ho preferito perderci un po in questo punto e trovare una via di mezzo
I tempi di esecuzione che citi nel tuo caso non vogliono dire molto se non si sa cosa fa il tuo CMS, che tipo di dati elabora, che quantita' di dati elabora, su che macchina/e gira, ecc.
verissimo, era giusto per fare un esempio, anche se capisco che è abbastanza vado
Per quanto riguarda la scelta di interfaccia, IMHO usare ancora le funzioni mysql_* e' follia, principalmente perche' non hai nemmeno i prepared statements, ma anche perche' sono funzioni di una libreria ormai vecchia e del tutto superata da PDO.
definirla follia è assurdo e sbagliato e si basa su dei preconcetti che non capisco
hai mai guardato il sorgente dell'estensione mysql di php? non è altro che un'interfacciamento (quasi) 1 ad 1 delle funzioni esposte dalla libreria nativa di mysql (o mysqlnd) stessa
se su questo costruisco il mio layer di astrazione, che vantaggio concreto mi da PDO? fa la stessa cosa che faccio io solo che lui la fa direttamente in C nell'estensione?
Ma a parte quello non mi da nessun vantaggio concreto, in quanto le posso reimplementare nel mio layer di estrazione.
Da un punto di vista di performance, non ho mai valutato PDO in modo approfondito, ma dai test (superficiali) che ho fatto il mio layer di astrazione perdeva contro PDO quando si lavorava con le migliaia di query eseguite
detto questo, personalmente non faccio uso dei prepared statement perché il loro vantaggio principale, tutto sommato, è quando lanci molte volte la stessa query ma non lancio mai 2 query di select uguali, e per le query di insert (che uso in particolari condizioni anche per gli update di massa) utilizzo l'on duplicate key insieme all'inserimento multiplo di valori
qualcosa tipo
codice:
INSERT INTO
tabella
(
campo1,
campo2,
campo3,
campo4,
campo5
)
VALUES
(1,2,3,4,5),
(6,7,8,9,10),
(11,12,13,14,15)
ON DUPLICATE KEYS UPDATE
campo1 = VALUES(campo1),
campo2 = VALUES(campo1),
campo3 = VALUES(campo3),
campo4 = VALUES(campo4),
campo5 = VALUES(campo5)
che fa il suo lavoro in modo egregio, veloce e performante
mi devo solo preoccupare di rispettare i vincoli delle chiavi, ma in generale lo si fa anche con gli update quando si imposta la where, casi particolari a parte, quindi non ho il problema
per quanto riguarda l'escape dei valori, ho un sistema che si basa su mysql_real_escape_string/vsprintf e funziona in modo semplice ed è abbastanza veloce
Poi non ho capito perche' dai per scontato che una libreria ORM aggiunge un sacco di complessita' e penalizza le prestazioni mentre la tua libreria personale no
Magari sei il programmatore piu' bravo del mondo ed e' vero, pero' mi sembra poco saggio scartare a priori soluzioni che comunque sono abitualmente usate in produzione da progetti molto grandi
nono, non voglio scartare a priori una libreria ORM, assolutamente, ogni tanto gli butto un occhio (come mi avete fatto fare in questi giorni ... anche se tempo ne ho poco e a parte scaricare doctrine2 e iniziare a guardare la doc non ho fatto)
ma ci sono 3 punti fondamentali:
- per mia politica personale, codice di terze parti non ne uso quando possibile (infatti uso quella cosa pesantissima di TCPDF ... avevo seriamente pensato di usare http://cairographics.org/cairo-php/ ma sono in beta ed ho lasciato perdere 
)
- conosco a fondo il mio framework ed il mio sistema, implementare il supporto a doctrine, per quanto possa essere semplice in fondo, non è la mia priorità visto che ci sono cose più importanti, alcune da emergenza rossa (non le dico per non svergognarmi, ma non ho tempo di sistemarle 
)
- rispetto agli strumenti che mi sono realizzato, quale vantaggio può REALMENTE darmi doctrine?
La risposta all'ultima domanda è che, mentre sicuramente può darmi dei vantaggi, non so fino a che punto possa veramente avvantaggiarmi visto che, vagamente, il mio sistema per mappare il database agli oggetti (mi permetto di chiamarlo così anche se è improprio) mi gestisce le situazioni che fino ad oggi ho incontrato (e ti assicuro che sono state veramente le più variegate)
Rispondi quotando
