[ARTICOLO] I layer di astrazione dal database

[Fabio Heller]

Gli strumenti a disposizione di chi vuole scrivere applicazioni PHP senza fossilizzarsi su un unico database

Parte prima: panoramica
http://freephp.html.it/articoli/view...olo.asp?id=127









Raga' sto diventando un ritardatario cronico...sto facendo impazzire Francesco

[}gu|do[z]{®©]

ci voleva

[andr3a]

non c'e' la mia classe astratta per MySQL e SQLite



















... ovviamente sto scherzando, bell' informazione, credevo ci fosse pear e poco altro, invece noto che il panorama e' ben piu' vasto, grazie per le info :metallica

[daniele_dll]

ottimo fabio
ma purtroppo tutti quei layer convertono la query e usano le reg expr per fare la conversione con il risultato che ad es se dovessi usare una query di mysql su postgresql mi dovrebbe lanciare almeno 1 preg_replace per ogni query :\

metti che ho 10 utenti contemporanei a rotazione...e il mio sito fa un 10\15 query...ci sarebberò +/- almeno 100\150 preg_replace :\

[Fabio Heller]

Ciao Daniele,
che io sappia non funzionano così: i più avanzati (Metabase, MDB e ADODB) si limitano ad utilizzare tipi sql propri (che poi traducono in quelli specifici per il database) e a fornire l'escape dei caratteri specifico per il singolo database.
Le espressioni regolari non vengono usate, o almeno non per quello che dici tu perchè non si tenta neppure di tradurre l'SQL.

Il massimo che si riesce a fare è fornire un modo neutro per eseguire un LIMIT x,y etc.etc.

Il discorso sull'SQL, come si vedrà nella seconda parte, non è del tutto risolvibile e le espressioni SQL non standard vanno trattate come si trattano le traduzioni in diversi linguaggi.




X Andrea.....

Cavolo, me l'ero dimenticato!!
Già che ci sono aggiungo anche questi (che ho lasciato fuori in quanto non credo continuino ad essere sviluppati)

L'ormai storica phpLib (chi ha programmato in PHP3 le vuole ancora bene)
http://phplib.sourceforge.net/index.php3

E patDBC
http://www.php-tools.de/site.php?file=misc/patDbc.xml

P.s. hai letto che ADODB esiste anche per Python? Sostiene di essere per certi versi migliore della libreria ufficiale....

[andr3a]

Originariamente inviato da Fabio Heller
X Andrea.....
Cavolo, me l'ero dimenticato!!

e ci mancherebbe ... l'unica cosa d'astratta che c'ha e' il codice che c'ho messo dentro

Originariamente inviato da Fabio Heller
P.s. hai letto che ADODB esiste anche per Python? Sostiene di essere per certi versi migliore della libreria ufficiale....

Non mi sono ancora immischiato con i db in Python perche' non sono riuscito a compilarmi SQLite a dovere ... appena riesco a fare qualcosa e a provare un layer ti faccio sapere

[daniele_dll]

Originariamente inviato da Fabio Heller
Ciao Daniele,
che io sappia non funzionano così: i più avanzati (Metabase, MDB e ADODB) si limitano ad utilizzare tipi sql propri (che poi traducono in quelli specifici per il database) e a fornire l'escape dei caratteri specifico per il singolo database.
Le espressioni regolari non vengono usate, o almeno non per quello che dici tu perchè non si tenta neppure di tradurre l'SQL.

Il massimo che si riesce a fare è fornire un modo neutro per eseguire un LIMIT x,y etc.etc.

Il discorso sull'SQL, come si vedrà nella seconda parte, non è del tutto risolvibile e le espressioni SQL non standard vanno trattate come si trattano le traduzioni in diversi linguaggi.

mmm dando una struttura personale la cosa si complica terribbilmente xche non solo le query sono, travigolette, limitate di per se, ma comunque viene eseguito un saccoooo di codice in + inutile :\

su nemesibb infatti stiamo vedendo cosa e come fare, abbiamo un'ideuzzola per la mente e forse usiamo quella, xo se c'è di meglio di certo non rifiutiamo, xo...il discorso è quello

ALMENO devi instanziarti 1 paio di classi per gestire il db, poi ci sono le classi che dividono il result set dalla classe di gestione del db e quindi vai a finire su una instanziazione per ogni query di select :\

x questo non mi convincono molto :\

[Fabio Heller]

L'overhead è innegabile, ma riguarda la programmazione a oggetti in genere e non i layer nello specifico (tra l'altro ci sono i link ai benchmark nell'articolo).

Mettiamola così:

Il progetto è piccolo e non sarà mai davvero sotto pressione-> non ti accorgerai dell'overhead

il progetto è importante-> il vantaggio dato dal layer di astrazione è, secondo me, irrinunciabile e se ti accorgi di problemi utilizzi un bel compilatore di bytecode...o migliori l'hardware

Siti come phpclasses si servono di METABASE che, in assoluto, è il più pesante dopo ODBC

[daniele_dll]

mmm

si ma credo che un sito come phpclasses faccio un numero abbastanza ridotto di query al database :\ e poi nn gliene frega un granché della velocità dato che utilizzano, se nn erro, db2

tu lo sai, il mio pallino sono prima la funzionalità, ma poi le prestazioni ed il carico effettivo sul server

quindi preferisco fare ad es una struttura un po + particolare ma che mi carichi meno roba possibile e sia + veloce possibile

sono proprio i bench a farmi paura...il doppio del tempo

[Fabio Heller]

Originariamente inviato da daniele_dll
sono proprio i bench a farmi paura...il doppio del tempo

Nell'altro benchmark non si vede il doppio, comunque molto dipende da come viene fatto

Io per praticità ho deciso che non uso più nessuna funzione specifica ma solo layer. Ho smesso di preoccuparmi troppo dei bench da quando mi mettono sempre fretta e uso gli oggetti, se devo programmare a oggetti lo faccio (cercando di farlo bene) e devo ancora vedere un'applicazione davvero troppo lenta.