PDO non mi garba quasi niente - Parliamone

[daniele_dll]

comunque, anche se un po ot, io mi domando

ma serve VERAMENTE usare un Database Abstraction Layer dato che comunque va fatto un notevole lavoro di "conversione" delle query che è 100 se non 1000 volte superiore a quello di convertire il codice per farlo andare con le librerie di un altro database?

per intenderci:
se ho una classe che mi fa da wrapper a tutto ... se, disgraziatamente, dovessi andare a convertire il mio applicativo da mysql a postgresql dovrei, oltre a convertire le varie chiamate, lavoro si e no di qualche ora, deve convertire TUTTE le query

e comunque quando si sviluppato un'applicativo si sviluppa avendo come target un database ed un linguaggio ed un webserver ... cambiare database vuol dire cambiare 1/3 della progettazione a "run-time"

[chris]

Originariamente inviato da daniele_dll
comunque, anche se un po ot, io mi domando
[...]
e comunque quando si sviluppato un'applicativo si sviluppa avendo come target un database ed un linguaggio ed un webserver ... cambiare database vuol dire cambiare 1/3 della progettazione a "run-time"

Vabbè, dipende dall'uso che fai delle funzioni specifiche di un determinato rdbms.

Imho, in ambiente web si potrebbe tranquillamente usarlo, ma le query dovrebbero essere scritte quanto più possibile in ANSI sql-92.

Se poi ti impunti ad usare la sintassi specifica di un rdbms allora ti stai impiccando da solo e quando farai il passaggio dovrai ingegnarti a toglierti il cappio :E

[skidx]

Originariamente inviato da daniele_dll
deve convertire TUTTE le query

Beh dai, mica tutte.
Se usi il più possibile SQL standard ti resta non tantissimo da cambiare.
In questo senso ho notato con piacere che nel MySQL stanno inserendo anche alias di funzioni per avere una sintassi comune con altri DBMS.

Un'altra cosa che mi sarebbe piaciuta avere nel PDO è la possibilità di chiamare funzioni proprietarie del Driver che sto usando.
Cioè, per tutte le funzioni comuni c'è l'interfaccia PDO, ma volendo, tramite la stessa classe PDO, avere un metodo per chiamare i metodi proprietari del driver. Sarebbe stata più portabile, sempre secondo me.

[riccardone]

Ho letto l'interessante thread e probabilmente iniziero ad usare pdo nonostante i pareri contrastanti (se non altro xche' mi sembra offra anche una buona gestione dei parametri).

Originariamente inviato da chris
Se poi ti impunti ad usare la sintassi specifica di un rdbms allora ti stai impiccando da solo e quando farai il passaggio dovrai ingegnarti a toglierti il cappio :E

ma... in una applicazione del mondo reale non mi e' mai capitato di scrivere molte query al 100% compatibili con lo standard sql (basta pensare al comodo limit di mysql, alle union che a volte vanno a volte no, al mettere insieme piu colonne, ai join che alcune versioni di oracle gestiscono con una sintassi diversa ecc. ecc. ecc.).
E cosi di solito quando nelle specifiche c'e' la compatibilita' con piu' dbms strutturo la logica in sintesi cosi (il pattern e' piuttosto diffuso)
client->manager->factory->dal->(qui credo possa starci pdo)->db
il livello manager offre al client tutti i metodi che gli servono e il pattern abstract factory nasconde le implementazioni concrete per i vari dbms. L'implementazione concreta dei vari metodi (query comprese) sta nel dal. Se si vuole aggiungere la compatibilita' con un nuovo dbms si aggiunge un nuovo dal (convertendo quindi quello che e' necessario convertire).
Il pdo svolge un servizio utile ma che si puo' fare anche a meno ai fini della compatibilita' con n database.

[skidx]

Originariamente inviato da riccardone
basta pensare al comodo limit di mysql

Giusto a pennello con quello che dicevo prima:

For compatibility with PostgreSQL, MySQL also supports the LIMIT row_count OFFSET offset syntax.

Io uso sempre quest'ultima sintassi infatti. Non sarà compatibile con ORACLE magari (boh, l'ho sparata), ma è già un passo avanti.

[daniele_dll]

si però quello che volevo dire io ... che senso ha? se io progetto un'applicativo per un DB a cosa serve predisporlo ad un 1/6 per un'altro DB?

è vero che le query standard funzionerebberò tranquillamente ma molto spesso si usando le date in formati particolari, si usano funzioni particolari del db e altro ancora

ovviamente dipende dall'ambito nel quale si è, però se devo essere sincero mi è capitato raramente di lavorare con altri database ma comunque non per porting di applicativi ma per progettazione diretta

[skidx]

Originariamente inviato da daniele_dll
si però quello che volevo dire io ... che senso ha? se io progetto un'applicativo per un DB a cosa serve predisporlo ad un 1/6 per un'altro DB?

Per dover cambiare meno roba in caso di porting?

Nella pratica effettivamente anche io faccio come te, nel senso che non è solo questione di query, il dbms influenza anche in fase di progettazione.
Ad esempio se so che il mysql mi offre certe cose e altre no, strutturo le tabelle in un certo modo piuttosto che in un altro, e così via.

Ad esempio, nell'applicazione che sto sviluppando gestisco i possibili deadlock delle transazioni in maniera trasparente (la transazione viene rieseguita un TOT di volte in caso di deadlock), perché so che nel mysql possono capitare (raramente, ma mi andava di gestirli). Sinceramente non lo so se questa gestione dei deadlock è sensata, usando un altro database, quindi forse c'è il rischio di perdere un po' di tempo dietro astrazioni poco utili (tranne nel caso in cui la portabilità sia un prerequisito sin dall'inizio, chiaro).

[daniele_dll]

Originariamente inviato da skidx
Per dover cambiare meno roba in caso di porting?

quando ho dovuto lavorare con DB2 ho convertito il mio wrapper di mysql in quello per db2 (tramite odbc) in meno di mezz'ora

Nella pratica effettivamente anche io faccio come te, nel senso che non è solo questione di query, il dbms influenza anche in fase di progettazione.
Ad esempio se so che il mysql mi offre certe cose e altre no, strutturo le tabelle in un certo modo piuttosto che in un altro, e così via.

Ad esempio, nell'applicazione che sto sviluppando gestisco i possibili deadlock delle transazioni in maniera trasparente (la transazione viene rieseguita un TOT di volte in caso di deadlock), perché so che nel mysql possono capitare (raramente, ma mi andava di gestirli). Sinceramente non lo so se questa gestione dei deadlock è sensata, usando un altro database, quindi forse c'è il rischio di perdere un po' di tempo dietro astrazioni poco utili (tranne nel caso in cui la portabilità sia un prerequisito sin dall'inizio, chiaro).

nel caso sia un requisito fondamentale preferisco implementare anche un layer di astrazione per le query e non solo per le funzioni del database

[andr3a]

boh, state prlando del doppio del lavoro contro il triplo del lavoro ... che senso ha ?


che senso ha dover riscrivere le classi, le chiamate al database o tutte le funzioni più comunque tutte le query, quando in pdo di queste 3 o 4 cose basta riscrivere solo le query e fare giusto un paio di accorgimenti a seconda del DB scelto ?

riscrivere tutto query comprese oppure riscrivere solo le query ed avere finalmente ciò che mancava solo al php ? ... a volte non vi capisco proprio, era meglio quando si stava peggio ?

[skidx]

Originariamente inviato da andr3a
quando in pdo di queste 3 o 4 cose basta riscrivere solo le query

Beh, noi stavamo dicendo proprio questo, che cioè talvolta non basta riscrivere solo le query, perché spesso anche altri pezzi del programma sono progettati in funzione di alcune caratteristiche del database.

Detto questo, ribadisco, per me ben venga PDO, a parte alcuni problemucci trovo che l'idea sia abbastanza positiva.