Query Abstraction Layer - suggerimenti e consigli

[daniele_dll]

hola a todos,

dato che per adesso sono relegato a casa per via di malanni vari sto passando un poco di tempo e volevo sviluppare un Query Abstraction Layer per il mio Database Abstraction Layer (il QAL mi serve per poggiarci su sviluppare, ancora più dopo, un ORM )

Ho dato un occhiata un pò qua e la e, inizialmente, pensavo di realizzare un sistema a cui passavo gli array per definire la query ma, parlando con alcune persone, mi sono reso conto che effettivamente è troppo macchinoso.

Una delle alternative è quella di scrivere un linguaggio SQL intermedio, o prendere un linguaggio SQL specifico da convertire con i vari driver, e tramite un parser poi interpretarlo ed eseguirlo. Soluzione sicuramente interessante però macchinosa perché ci vuole un parser che faccia tante operazioni

Guardando un pò qua e la ho notato doctrine che è un ORM è per il suo sistema utilizza un qualcosa di molto carino, qui c'è un esempio

$q = new Doctrine_Query();

$rows = $q->update('Account')
          ->set('amount', 'amount + 200')
          ->where('id > 200')
          ->execute();

sinceramente, io, vorrei fare qualcosa di più nel senso che ora come ora se pur estremamente flessibile secondo me puè essere espando ancora di più

Volevo scrivere un sistema simile, qualcosa tipo

$query = new QAL_Query();

$query->select()
  ->fields('tabella1.campo1', 'tabella1.campo2 AS campo4', 'tabella2.campo3')
  ->field('tabell2.anotherfield')
  ->from('tabella1')
  ->innerjoin()->with('tabella2')->using('tabella2.indice=tabella1.indice')
  ->where()->field('tabella1.campo1='TEST')

ora, questo sistema, allunga leggermente il codice, però credo renda il tutto leggermente più leggibile

il problema è però che così si è comunque ed in ogni caso costrutetti ad usare un po di SQL dentro i vari campo con la conseguenza che alcune query potrebberò non essere compatibili! Al che pensavo di espandere il tutto ancora di più ma si tradurrebbe in qualcosa tipo

$query = new QAL_Query();

$query->select()
  ->fields('tabella1.campo1', 'tabella2.campo3')
  ->field('tabella1.campo2')->as('campo4')
  ->field('tabell2.anotherfield')
  ->from('tabella1')
  ->innerjoin()->with('tabella2')->using('tabella2.indice')->equal('tabella1.indice')
  ->where()->field('tabella1.campo1')->equal('TEST')

cosi riduco un pò il tutto ... però mettiamo che debba mettere l'estrazione di un count con un group by

$query = new QAL_Query();

$rows = $query->select()
  ->fields('tabella1.campo1', 'tabella2.campo3')
  ->field('tabella1.campo2')->as('campo4')
  ->field('tabell2.anotherfield')
  ->value('valorefisso')
  ->field()->count('*')->as('conteggio')
  ->field()->concat()->value()->field('campo1')->value('|')->value()->field('campo2')
  ->from('tabella1')
  ->innerjoin()->with('tabella2')->using('tabella2.indice')->equal('tabella1.indice')
  ->where()->field('tabella1.campo1')->equal('TEST')
  ->groupby('campo4')
  ->execute();

in pratica i vari comandi SQL si "traducono" in una sequenza di metodi dell'oggetto della query

ora ... la comprensibilità di una cosa del genere non sono propriamente molto convinto che sia superiore perché effettivamente c'è un gran bel casino! ... a livello di prestazioni credo che si dovrebbe comunque stare sotto i tempo del parser però se la leggibilità e la manutentibilità del codice rasenta lo zero, effettivamente non so più la convienenza di un sistema troppo precisino.
Questo sistema, l'unica cosa che si ritroverebbe a fare, è a segnare le varie condizioni ... per esempio un metodono value richiamato senza parametri indica al sistema che lo stato corrente è WaitingAValue oppure un campo field vuoto WaitingAField in modo che il count presente dopo il field dica al sistema che il campo è un COUNT su * ... e l'as presente dice al sistema che il Field o il Value precedente ha quello specifico alias

voi che suggerite?

[andrea.paiola]

Originariamente inviato da daniele_dll
voi che suggerite?

di fare come tutti (o quasi ): ossia semplificare le query più frequenti ( dalla select agli insert, con transazioni ), ma lasciare la possibilità di inserire il codice SQL nudo e crudo


conosci ActiveRecord? http://wiki.rubyonrails.org/rails/pages/ActiveRecord

il QUANTO semplificare e QUANTO avvicinarsi al SQL sono scelte progettuali che in parte dipendono anche da che ORM poi vuoi andare a fare...

magari dai un occhio anche a SQLAlchemy http://www.sqlalchemy.org/

in alternativa ( ma anche no ) si può pensare di creare un generatore semiautomatico di query SQL sullo stile di erlsql http://yarivsblog.com/articles/2006/...nts-in-erlang/

[andr3a]

propel

[daniele_dll]

Originariamente inviato da andr3a
propel

si l'avevo visto, ma a me interessava un parere su quello che avevo scritto su, non qualche link buttato qua e la

per la cronaca: propel lo avevo scartato a priorio per il semplice motivo che lavorando da solo, e quindi non avendo tempo a sufficenza per ogni singola fase dello sviluppo (compreso per quella del database) una variazione a posteriori di una o più tabelle comportano la riscrittura o modifica del file XML oltre che la rigenerazione dei file file php

L'orm che mi svilupperò, per quanto riguarda le mie necessità, lavorerà a runtime, nel senso che i raccordi complessi li descrivo tramite php

sicuramente propel, sotto questo specifico punto di vista, è più efficente (non so in generale), però è abbastanza seccante dover manutenere altri file aggiuntivi per gestire tutto il progetto

[andr3a]

il file XML lo genera propel stesso ... ma se cambi qualcosa, si vede che il progetto era mal concepito o non abbastanza flessibile, a livello di schema.

Qualunque struttura, qualunque applicativo, se cambi il database sotto nella migliore delle ipotesi perdi una settimana a far funzionare tutto come desiderato.

Io so come pensi i db, e non sei di quelli che li cambiano ogni 3 mesi tanto chissene frega ... sei un maniaco delle performances, schiaffi su propel e sei a cavallo ^_^


P.S. propel è usato da Symfony, Symfony è quello che reputo il miglior framework PHP5 ed è tra i pochi Enterprise. Drupal viene poi, e mi sembra si basi anch'esso su propel ... quando dovevo pensare ad un'alternativa, la scelta era tutto a mano o propel ... non ce n'erano altre così valide.
Detto questo, layer SQL? rinunci a qualcosa, sempre ... o ti perdi nested queries, o ti perdi transazioni, insomma, se alla fine il layer ha eccezioni tanto vale usare PDO e query dedicate a seconda del DB con poche automazioni e molto più controllo sulla sintassi nuda e cruda

[daniele_dll]

Originariamente inviato da andr3a
il file XML lo genera propel stesso ... ma se cambi qualcosa, si vede che il progetto era mal concepito o non abbastanza flessibile, a livello di schema.

è quello che ho appena detto su ^^ bisogna essere realisti ... difficilmente si ha il tempo giusto per svolgere a PIENO tutte le fasi del progetto

Qualunque struttura, qualunque applicativo, se cambi il database sotto nella migliore delle ipotesi perdi una settimana a far funzionare tutto come desiderato.

beh, per le modifiche io intendevo in fase di sviluppo e comunque non su roba che già ho sviluppato, le pezze tento di evitarle in tutti i modi

Io so come pensi i db, e non sei di quelli che li cambiano ogni 3 mesi tanto chissene frega ... sei un maniaco delle performances, schiaffi su propel e sei a cavallo ^_^

si infatti come ti ho scritto, propel è sicuramente più efficente sotto questo punto di vista

P.S. propel è usato da Symfony, Symfony è quello che reputo il miglior framework PHP5 ed è tra i pochi Enterprise. Drupal viene poi, e mi sembra si basi anch'esso su propel ... quando dovevo pensare ad un'alternativa, la scelta era tutto a mano o propel ... non ce n'erano altre così valide.
Detto questo, layer SQL? rinunci a qualcosa, sempre ... o ti perdi nested queries, o ti perdi transazioni, insomma, se alla fine il layer ha eccezioni tanto vale usare PDO e query dedicate a seconda del DB con poche automazioni e molto più controllo sulla sintassi nuda e cruda

ti dirò, negli applicativi web hai poca necessità di usare le nested query, quelle poche volte che ne avrei avuto bisogno ho aggirato la cosa usando una seconda query è la clausola IN nel where (si, non è il massimo, ma è una query su 100 )

Sinceramente sono sempre un postato "scettico" dei sistemi ORM e dei database ad oggetti, infatti non ne ho mai usati fino ad adesso, però sinceramente mi ritrovo nella situazione di dover sviluppare un gestionale e penso che potrei ridurre veramente i tempi di sviluppo usando un ORM dato che nel gestionale l'accesso al database, tranne per la parte statistica, è abbastanza "standard" ... i collegamenti che ci stanno sono semplici e lineari

[andr3a]

hibernate e spring sono tra i progetti più utilizzati del mondo Enterprise ... quello Java. Noi in PHP siamo scettici perchè qualunque ORM schiaffi su perdi 3 volte tanto, se ti va bene, in performances ... ma di base, l'ORM, è indispensabile per grandi progetti, o meglio, semplifica la vita.

Poi se invece di MySQL 4 hai il 5 o meglio ancora qualcos'altro, sei a posto perchè per le operazioni complicate sfrutti strumenti dello stesso DB, invece di morire di un colpo come sto facendo io al lavoro per creare a mano le materialized view di Oracle su MySQL 4

[andrea.paiola]

Originariamente inviato da andr3a
Poi se invece di MySQL 4 hai il 5 o meglio ancora qualcos'altro...

beh però se pensi il progetto su un db specifico perdi uno dei vantaggi dato dal layer, ossia l'indipendenza dal db... alla fine la scelta dipende sì da cosa devi fare, ma anche da quanto tempo ( ossia budget ) hai per farlo: il RAD,l'agile software development e i relativi framework alle volte sono irrinunciabili... per le performance... beh pazienza, in diversi casi basta aggiungere un po' di hardware e risolvi...

[andr3a]

se vuoi il massimo dal db non puoi astrarre .. se puoi farlo, ed usi PHP, il layer è pesante.

I database hanno caratteristiche differenti, se non ci sono transazioni, emularle è un rischio, se ci sono, perchè non usarle, per avere compatibilità con versioni obsolete? E quanto costano queste compatibilità?

PDO è nato leggero e poco astratto rispetto il pesante ADO proprio per questi motivi, hai libertà di sfruttare un'API ma le query sono una cosa aparte, come i parametri da impostare.

Con PDO puoi usare qualunque db compatiile, scrivere un buon costruttore parametrizzato a seconda delle esigenze, sfruttare query scritte appositamente per quello o quell'altro database ed avere sempre il meglio dal sistema che utilizzi ... ma anche qui, se aggiungi mille swith, if else, o altro, per rendere PDO più astratto e sfruttarlo tramite wrapper, perdi in performances ... e se in più rinunci ad alcune caratteristiche del DB, non si tratta sempre di qualche decina di millisecondo, in progetti corposi può trattarsi di minuti.

Il db ha la fortuna/sfortuna di richiedere un driver, ergo non puoi scrivere un layer sintattico che da solo sia in grado di risolvere quella o quell'altra problematica ... se lo fai è un layer facile facile, che magari va bene per il 70% dei casi, ma se il progetto è corposo, al 99% non andrà bene.

Bisogna sempre valutare cosa si deve fare e quali sturmenti si hanno (prendete qualche forum, compatibile con quello o quell'altro ... il numero di compatibilità dei DB è sempre limitato per queste ragioni)

[daniele_dll]

Originariamente inviato da andr3a
hibernate e spring sono tra i progetti più utilizzati del mondo Enterprise ... quello Java. Noi in PHP siamo scettici perchè qualunque ORM schiaffi su perdi 3 volte tanto, se ti va bene, in performances ... ma di base, l'ORM, è indispensabile per grandi progetti, o meglio, semplifica la vita.

si ... in tutti gli altri linguaggi tranne che in php per l'appunto (in C# ne faccio uso ^^)

Poi se invece di MySQL 4 hai il 5 o meglio ancora qualcos'altro, sei a posto perchè per le operazioni complicate sfrutti strumenti dello stesso DB, invece di morire di un colpo come sto facendo io al lavoro per creare a mano le materialized view di Oracle su MySQL 4

come sai bene, certe cose è difficile scinderle, soprattutto quando il gestionale web va installato su un singolo pc
Userò SQLite per quest'occasione, come backend, anche se comunque mysqli lo devo implementare perché va rivenduto ad un altra ditta che ha più magazzini separati e ha quindi la necessità di centralizzare tutto il software e andrà il tutto su un server web dove non è un problema aumentare il numero di applicativi da usare