Gestionale GAzie (Open Source)
Stefano Cortelli
interessante progetto di gestionale scritto in PHP/MySql:
http://gazie.sourceforge.net/
Essendo ragioniere libero professionista, cerco ove possibile di proporre
soluzioni Open Source ai clienti, dove possibile. Ben venga quindi questo
progetto, portato avanti con impegno da alcuni anni.
Purtroppo a livello di gestione dati/database, a mio parere manca di
un'impostazione "robusta" e affidabile, che si richiede necessariamente ad
un software gestionale sul quale "girano" i dati aziendali. Ed � questo a
mio parere il principale limite alla diffusione di questo software. Per
gestione dati "robusta" intendo utilizzo di relazioni e transazioni, cosa
che manca del tutto sul software in questione, che utilizzando tra l'altro
le tabelle MyIsam, che non supportano n� transazioni n� foreign key.
Ho provato a convertire le tabelle con le InnoDb aggiungendo le relazioni
ottenendo un netto miglioramento, purtroppo occorrerebbero ulteriori
interventi sul codice PHP per inserire le transazioni e magari con
l'occasione apportare alcune migliorie.
E qui viene il punto: purtroppo non ho conoscenze di PHP, pur apprezzando
molto questo linguaggio di script, lavorando abitualmente su altri
linguaggi.
Ecco allora la ragione della mia proposta: ci sarebbero persone con
conoscenze di PHP interessate a contribuire ad una "sistemazione" di
questo interessante progetto? Credo che un lavoro "base", che lo
migliorerebbe gi� di molto, non sia un lavoro troppo lungo ed impegnativo
per chi gi� e' abituato a lavorare con PHP/MySql.
Da parte mia potrei occuparmi di tutto l'aspetto relativo al Db (creazione
delle relazioni, di nuovi indici, dell'architettura generale dei dati) e
fornire alcuni consigli su determinate funzionalita' che magari si
potrebbero aggiungere, credo di avere una buona esperienza in tal senso
avendo sviluppato una procedura gestionale con un altro linguaggio.
Il tutto sarebbe un contributo molto valido al mondo Open Source e PHP in
particolare.
Chiaramente, se lo staff di GAzie fosse interessato si potrebbe
collaborare insieme, ma in caso contrario ci sarebbe un'altra strada
grazie alla quale il software potrebbe diventare molto pi� utilizzabile
rispetto a come � ora.
Ho gi� provato ad inserire un messaggio nel forum di GAzie sulla richiesta
di features, ma non ho ricevuto nessun interessamento, e presumo quindi
che la cosa non sia di primario interesse per gli sviluppatori, forse pi�
interessati ad aggiungere funzionalit� che all'aspetto della gestione dei
dati (anche se spero di sbagliarmi):
http://sourceforge.net/tracker/?fun...amp;atid=717642
D'altro canto un gestionale che gira su un DB senza utilizzo di
transazioni e relazioni... non � certo il massimo dell'affidabilit�, ed �
un vero peccato visto che il progetto, a livello di funzionalit�, si
presenta invece interessante e con poca fatica potrebbe fornire quella
sicurezza sui dati che necessariamente si richiede ad un gestionale.
Un saluto a tutti,
Stefano
Studio Rag. Cortelli
www.studiocortelli.com
--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ab...@newsland.it
Andrea D'Amore
studiora...@tiscali.it (Stefano Cortelli) wrote:
[CUT]
> Stefano
Un sincero in bocca al lupo.
DaNieL
<and.damore...@LOSPAM.gmail.com.invalid> wrote:
> In article <hk6lkc$s7...@news.newsland.it>,
> studioragcorte...@tiscali.it (Stefano Cortelli) wrote:
>
> [CUT]
>
> > Stefano
>
> Un sincero in bocca al lupo.
Mi accodo.
una cosa simile c'è anche in java (nata da un paio d'anni mi sembra),
sempre opensource: http://www.notasoftware.com/
Stefano Cortelli
> On 2 Feb, 09:38, Andrea D'Amore
> <and.damore...@LOSPAM.gmail.com.invalid> wrote:
> > In article <hk6lkc$s7...@news.newsland.it>,
> > �studioragcorte...@tiscali.it (Stefano Cortelli) wrote:
> >
> > [CUT]
> >
> > > Stefano
> >
> > Un sincero in bocca al lupo.
> Mi accodo.
> una cosa simile c'� anche in java (nata da un paio d'anni mi sembra),
> sempre opensource: http://www.notasoftware.com/
Grazie dell'interessante link, la mia proposta era qualcosa di molto pi�
semplice, partendo da GAzie che come funzionalit� nel panorama Open Source
si presenta abbastanza completo.
Ho gi� fatto il porting con le InnoDb gestendo le relazioni.
Se qualcuno che lavora in PHP aggiungesse poche righe per iniziare /
terminare la transazione e gestire eventuali erorri (Start / Commit /
Rollaback) sugli inserimenti / modifiche del database sarebbe gi� un
grandissimo passo in avanti.
Se poi si riuscisse a mettere Null invece di 0 nei campi vuoti, sarebbe
poi perfetto.
Eventuali features da aggiungere sarebbero molto limitate e sarebbero
comunque facoltative (p.es. segnalare se si va sotto giacenza al momento
dell'emissione di un documento, ecc.).
Alcune cose le ho gi� sistemate io, pur non lavorando in PHP, come portare
il numero di sezionali IVA da 3 a 9.
Quello che volevo proporre, erano *piccoli* interventi - in considerazione
del fatto che GAzie � gi� un gestionale piuttosto completo - senza dover
mettere mano a tutto il codice.
In sostanza, l'idea non era di portare avanti un progetto fermo o
abbandonato, ma di apportare quelle modifiche che gli sviluppatori
originari non hanno ritenuto interessante fare, ma che sono a mio parere
indispensabili per garantire l'affidabilit� dei dati.
Qualcuno sarebbe disponibile?
Buona giornata a tutti,
Stefano
Hermooz
wrote:
> D'altro canto un gestionale che gira su un DB senza utilizzo di
> transazioni e relazioni... non è certo il massimo dell'affidabilità, ed è
> un vero peccato visto che il progetto, a livello di funzionalità, si
> presenta invece interessante e con poca fatica potrebbe fornire quella
> sicurezza sui dati che necessariamente si richiede ad un gestionale.
Ciao Stefano. La tua affermazione sulla diciamo "fragilità" del modo
in cui MySQL tutela i dati ad esso affidati è una delle top 10 nella
classifica delle flame bait sui NG tecnici (e con questo non voglio
dire che sia infondata o che i motivi dietro non siano validi), per
cui non c'e' da stupirsi se viene ignorata, in quanto chi è abituato a
sviluppare in MySQL in genere si è sentito sollevare la critica
svariate volte e o la capisce e passa ad un DB diverso oppure comincia
a classificarla come un insulto a mammasanta o giù di lì.
Per certi versi è anche vero che non è che per il fatto che
un'applicazione si appoggi ad un DB senza usare integrità referenziale
o transazioni necessariamente questa non sia stata progettata per
conservare la consistenza dei dati; semplicemente questo vuol dire che
l'onere di mantenerla deve essere nel codice applicativo anzichè nel
DB. A molti questo appare illogico (se è un mestiere che già fa il DB
e lo fa bene, perchè reinventare l'acqua calda?) ma è anche vero che
molti altri sono abituati a lavorare così, o perchè utilizzano come
layer di persistenza un DB non relazionale, o perchè per mantenersi la
possiblità di astrarlo spostano il controllo di integrità a livello di
ORM.
Venendo al merito della tua domanda, il fatto è che il cambio di
modalità è ben più radicale di quanto sembra tu abbia capito; cambiare
il supporto sottostante da myisam a innodb è il meno, il fatto è che
non basta aggiungere un "begin" e un "end" qua e là per sfruttare le
transazioni, così come non basta aggiungere le foreign key per far
funzionare l'integrità: l'intero flusso logico dell'applicativo va
ridisegnato per gestire in un caso il caso commit/rollback e
nell'altro per trappare le eccezioni e operare di conseguenza.
Tra l'altro, a dirla tutta, anche sobbarcandosi il lavorone di cui
sopra non avresti neanche raggiunto l'obiettivo che ti proponi perchè
comunque in MySQL, anche usando il supporto innoDB, il concetto di
integrità dei dati è concepito in maniera un po' allegrotta (cfr.
http://sql-info.de/mysql/gotchas.html) per cui l'unico modo di fare il
lavoro perbene sarebbe integrare in GAzie il supporto per DB diversi a
mysql, che non so quanto sia facile perchè dipende da come hanno
ingegnerizzato l'applicativo: ho dato una rapida occhiata e così
d'acchito direi che si parte male perchè non hanno utilizzato nessun
tipo di DB abstraction layer. Si rischia di metterci meno a rifare
tutto da capo...
bye!
DaNieL
> On 1 Feb, 14:40, studioragcorte...@tiscali.it (Stefano Cortelli)
> wrote:
>
> Ciao Stefano. La tua affermazione sulla diciamo "fragilità" del modo
> in cui MySQL tutela i dati ad esso affidati è una delle top 10 nella
> classifica delle flame bait sui NG tecnici (e con questo non voglio
> dire che sia infondata o che i motivi dietro non siano validi), per
> cui non c'e' da stupirsi se viene ignorata, in quanto chi è abituato a
> sviluppare in MySQL in genere si è sentito sollevare la critica
> svariate volte e o la capisce e passa ad un DB diverso oppure comincia
> a classificarla come un insulto a mammasanta o giù di lì.
>
> Per certi versi è anche vero che non è che per il fatto che
> un'applicazione si appoggi ad un DB senza usare integrità referenziale
> o transazioni necessariamente questa non sia stata progettata per
> conservare la consistenza dei dati; semplicemente questo vuol dire che
> l'onere di mantenerla deve essere nel codice applicativo anzichè nel
> DB. A molti questo appare illogico (se è un mestiere che già fa il DB
> e lo fa bene, perchè reinventare l'acqua calda?) ma è anche vero che
> molti altri sono abituati a lavorare così, o perchè utilizzano come
> layer di persistenza un DB non relazionale, o perchè per mantenersi la
> possiblità di astrarlo spostano il controllo di integrità a livello di
> ORM.
Hai la mia spada al 99% (anche se onestamente non affidrei mai solo al
codice la referenzialità dei dati), ma c'è anche da dire che le
tabelle myIsam sono molto più veloci... e più sottoposte a corruzioni.
Io provai una volta a passare a innodb su un progetto nato su myisam,
le query impiegarono quasi il doppio del tempo...
Per quel che riguarda l'affidabilità, anche se è difficile che in ogni
caso si massacri il db, le tabelle myisam sono più soggette a questa
cosa.. che per un gestionale aziendale non è proprio il massimo.
Hermooz
> Per quel che riguarda l'affidabilità, anche se è difficile che in ogni
> caso si massacri il db, le tabelle myisam sono più soggette a questa
> cosa.. che per un gestionale aziendale non è proprio il massimo.
Non stavo parlando di corruzioni, o almeno non solo di quelle - che
sono sempre un rischio e dalle quali ci si difende con i backup, in
quanto non esiste DB che te ne metta completamente al riparo.
In ambito DBMS quando ci si riferisce alla data integrity si intende
che il DB deve garantirti che i dati rispettino sempre lo schema che
tu hai definito. In altre parole, se hai una struttura master-detail
con relativa foreign key, è compito del DB assicurarsi che nessuno
tenti di inserire righe senza testata o viceversa che qualcuno tenti
di cancellare la testata lasciando righe orfane, se definisci un
costraint su un campo numerico che dice che i valori devono stare in
un certo range allora deve sollevare un'eccezione quando l'applicativo
tenta di inserli al di fuori, ecc. ecc.
Tutte cose che hanno un certo impatto sulle performance, è ovvio; ma
d'altra parte se le ignori per fare un DB "veloce" poi a fare gli
stessi controlli ci deve pensare l'applicativo, ed ecco che il
vantaggio te lo sei bello che giocato.
bye!
Pippk
"Stefano Cortelli" <studiora...@tiscali.it> ha scritto nel messaggio
news:hk6lkc$s7l$1...@news.newsland.it...
> Un saluto a tutto il newsgroup. Da un po' di tempo ho trovato questo
Per chi mastica PHP da anni non sar� un problema.....il vero problema � che
si vuole fare qualcosa di OpenSource che non porta
alcun ritorno economico. Ci vorrebbe una persona che ha tempo da dedicarci e
che abbia voglia di sviluppare per beneficienza.
Io per esempio sto fuori casa 10 ore al giorno, poi mettici il tempo da
dedicare alla famiglia, il tempo per mangiare e qualcosa per
rilassarsi e delle 24 ore non resta niente. Con la crisi attuale ci vorrebbe
qualcuno che abbia un lavoro statale e che dopo le sue misere 6 ore abbia
voglia di dedicarsi allo sviluppo OpenSource.
Stefano Cortelli
risponderti nel testo:
> Per certi versi � anche vero che non � che per il fatto che
> un'applicazione si appoggi ad un DB senza usare integrit� referenziale
> o transazioni necessariamente questa non sia stata progettata per
> conservare la consistenza dei dati; semplicemente questo vuol dire che
> l'onere di mantenerla deve essere nel codice applicativo anzich� nel
> DB.
E'vero, anche se a mio parere la gestione a livello di DB � sempre pi�
performante, non solo perch� funziona sempre ed in tutte le situazioni, ma
anche perch� garantisce la corretta gestione delle relazioni
indipendentemente da quello che potrebbe succedere in multiutenza
(ambiente dell'altro tipico per un gestionale). Magari in caso di accesso
"quasi contestuale" di due utenti, la situazione potrebbe sfuggire ad un
controllo a livello di applicativo.
Il problema, comunque, � che GAzie un controllo a livello di applicativo
lo fa solo qua e la': ho provato ad esempio a cancellare un articolo usato
in una fattura e me lo ha lasciato fare, stessa cosa per codici IVA,
banche, ecc.
> Venendo al merito della tua domanda, il fatto � che il cambio di
> modalit� � ben pi� radicale di quanto sembra tu abbia capito; cambiare
> il supporto sottostante da myisam a innodb � il meno, il fatto � che
> non basta aggiungere un "begin" e un "end" qua e l� per sfruttare le
> transazioni, cos� come non basta aggiungere le foreign key per far
> funzionare l'integrit�: l'intero flusso logico dell'applicativo va
> ridisegnato per gestire in un caso il caso commit/rollback e
> nell'altro per trappare le eccezioni e operare di conseguenza.
Sono d'accordo con te, infatti io ho scritto (con altro linguaggio) una
procedura amministrativa-contabile per il mio studio, e sono partito dalla
base dati (Firebird nel mio caso) e su questa ho scritto l'applicativo.
Per� aggiungendo le foreign key su GAzie un netto miglioramento c'� stato,
perch� adesso l'utente non puo' pi� cancellare l'articolo, la banca, le
condizioni di pagamento ecc. usate gi� in una fattura.
Per le transazioni non conoscendo PHP non posso esprimermi, anche se avevo
curiosato un po' sul Web e non mi sembrava cos� complesso: per quello che
riguarda la mia esperienza su ambiente Pascal (Lazarus) basta dare il
begin della transazione e con uno statement del tipo try commit / except
rollback prima e dopo un inserimento unitario (master + detail o
operazioni come la chiusura contabile, che devono essere esguite sempre
integralmente).
� davvero cos� complesso con PHP?
Avevo trovato questi link che non mi sembravano, come impostazione, cos�
diversi da come si opera con altri linguaggi:
ttp://www.devarticles.com/c/a/MySQL/Using-Transactions-with-MySQL-4.0-and-PHP/
http://www.databasejournal.com/features/mysql/article.php/3382171/Transactions-in-MySQL.htm
> Tra l'altro, a dirla tutta, anche sobbarcandosi il lavorone di cui
> sopra non avresti neanche raggiunto l'obiettivo che ti proponi perch�
> comunque in MySQL, anche usando il supporto innoDB, il concetto di
> integrit� dei dati � concepito in maniera un po' allegrotta (cfr.
> http://sql-info.de/mysql/gotchas.html)
Questo non lo sapevo, avevo fatto ricerche riguardo le InnoDb (sviluppate
dalla Oracle) e mi sembrava che l'unico aspetto negativo (a parte la
maggiore lentezza, ma le MyIsam sono pi� veloci anche perch� appunto non
devono gestire controlli e relazioni di nessun tipo) fosse quello di dover
fare periodicamente un backup-restore del database (da quello che ho visto
le InnoDb non fanno automaticamente il Pack dei dati per cui in caso di
cancellazioni numerose, peraltro improbabili in un gestionale, il db
cresce sempre di dimensioni).
Ho visto che anche altri applicativi di tipo CRM utilizzano MySql con le
InnoDb (VTiger, Dollibar, ecc.) per poter avere relazioni e transazioni.
per cui l'unico modo di fare il
> lavoro perbene sarebbe integrare in GAzie il supporto per DB diversi a
> mysql,
Qui sono completamente d'accordo con te, una soluzione con PostgreSql e/o
Firebird sarebbe eccellente.
> che non so quanto sia facile perch� dipende da come hanno
> ingegnerizzato l'applicativo: ho dato una rapida occhiata e cos�
> d'acchito direi che si parte male perch� non hanno utilizzato nessun
> tipo di DB abstraction layer. Si rischia di metterci meno a rifare
> tutto da capo...
Da quello che ho visto in /library/include/ c'� un file denomianto
mysql.lib.php, mentre in /config/config/ il file gconfig.php indica la
variabile:
$NomeDB = "mysql";
Forse sbaglio, ma magari il passaggio ad un Db pi� adatto potrebbe essere
fattibile...
O mi sbaglio?
A questo punto, riterresti fattibile la cosa, non importa se con le
InnoDb, PostgreSql o Firebird o cos'altro?
Cio�, la situazione sarebbe questa: � disponbile questo software Open
Source, che tra l'altro, � tutt'ora supportato, vengono periodicamente
rilasciate release, ha le principali funzionalit� che si richiedono ad un
gestionale.
Senza dover rifare tutto, pensavo solamente a qualche *piccolo* intervento
(almeno nella mia immaginazione), qualcosa cio� di piccola portata:
- Aggiunta delle transazioni e relazioni o comunque controllo sui dati;
- Aggiunta di qualche piccola funzionalit� come la segnalazione se in sede
di fatturazione si va sotto la giacenza di un articolo;
- Supporto della gestione multiaziendale (oggi GAzie ha gi� una variabile
$Ditta e $Database, basterebbe nel login aggiungere un campo con il codice
ditta in modo che punti al database della ditta).
� vero che magari non sarebbe la stessa cosa che scrivere un programma da
zero impostato sulla gestione DB, ma se con poca fatica si pu� permettere
a questo progetto di essere di fatto usato in ambito aziendale... sarebbe
una bella cosa, anche perch� di Open Source multipiattaforma le proposte
alla fine non sono tantissime, e questa avrebbe un'interfaccia anche
user-friendly...
Tu cosa dici?
Ancora grazie e buona giornata,
Stefano
> bye!
Hermooz
wrote:
> indipendentemente da quello che potrebbe succedere in multiutenza
> (ambiente dell'altro tipico per un gestionale). Magari in caso di accesso
> "quasi contestuale" di due utenti, la situazione potrebbe sfuggire ad un
> controllo a livello di applicativo.
la concorrenza la devi comunque gestire SEMPRE in un applicativo
multiutente client-server, altrimenti sei fottuto a priori, scusa il
francesismo ;^)
> Il problema, comunque, è che GAzie un controllo a livello di applicativo
> lo fa solo qua e la': ho provato ad esempio a cancellare un articolo usato
> in una fattura e me lo ha lasciato fare, stessa cosa per codici IVA,
> banche, ecc.
Brrrr...
> Però aggiungendo le foreign key su GAzie un netto miglioramento c'è stato,
> perché adesso l'utente non puo' più cancellare l'articolo, la banca, le
> condizioni di pagamento ecc. usate già in una fattura.
Sì, OK, hai bloccato la possibilità di causare disallineamenti nella
base dati, ma quando il programma si becca un'eccezione di integrità
violata sostanzialmente... muore in maniera anomala, dato che è
un'eccezione non originariamente prevista dai programmatori. Quindi
non sappiamo quello che succede esattamente, magari in qualche modo
l'utente essendo un'applicazione web può continuare a lavorare
cliccando su "back" o con altro modo, ma ormai la logica di control
flow originale del programma è andata a farsi benedire. Il risultato è
impredicibile. Per ogni query dove è possibile che venga sollevato un
errore del genere va aggiunta la logica per intercettare l'errore e
riportare l'applicativo ad uno stato coerente, in genere.
> riguarda la mia esperienza su ambiente Pascal (Lazarus) basta dare il
> begin della transazione e con uno statement del tipo try commit / except
> rollback prima e dopo un inserimento unitario (master + detail o
> operazioni come la chiusura contabile, che devono essere esguite sempre
> integralmente).
> È davvero così complesso con PHP?
No, più o meno è uguale. Ma come sopra, se ti limiti a mettere un
begin e un end non hai risolto nulla: devi metterci anche un test per
vedere se la transazione è riuscita o no e gestire in qualche modo il
commit e il rollback - quanto meno, all'utente glielo vodrai dire se è
andato tutto bene o no!
E ancora, questo va fatto *per ogni* transazione in *ogni* punto del
codice in cui c'e' la possibilità di errore - cioè sempre, temo.
Ma soprattutto, a priori devi ricostruire tutta la logica delle
modifiche per capire cosa fa parte di una transazione e cosa no.
Per spiegarmi meglio, se in un punto del programma hai una funzione
che inserisce una riga in una tabella e in un altro ne hai un'altra
che fa un'update su una seconda tabella, come fai a sapere a priori se
sono da mettere in un'unica transazione o no? Magari l'update serve
per conteggiare quell'insert, per cui se fallisce l'insert deve
rollbaccare anche l'update. Se decidi a priori che ogni query di
modifica sul DB è una transazione a sè non guadagni molto rispetto a
lasciare tutto com'e'...
> Questo non lo sapevo, avevo fatto ricerche riguardo le InnoDb (sviluppate
> dalla Oracle)
No, sono state sviluppate dalla Innosoft, Oracle se le è solo comprate
recentemente.
> Da quello che ho visto in /library/include/ c'è un file denomianto
> mysql.lib.php, mentre in /config/config/ il file gconfig.php indica la
> variabile:
> $NomeDB = "mysql";
> Forse sbaglio, ma magari il passaggio ad un Db più adatto potrebbe essere
> fattibile...
fattibile certamente, ma sui tempi non mi sento di esprimermi :^)
> È vero che magari non sarebbe la stessa cosa che scrivere un programma da
> zero impostato sulla gestione DB, ma se con poca fatica si può permettere
> a questo progetto di essere di fatto usato in ambito aziendale... sarebbe
> una bella cosa, anche perché di Open Source multipiattaforma le proposte
> alla fine non sono tantissime, e questa avrebbe un'interfaccia anche
> user-friendly...
avrei qualche cosuccia da ridire anche sull'interfaccia, ma
soprassediamo :^)
Boh, così a pelle (prendilo con beneficio d'inventario, mica mi sono
messo a fare un'analisi approfondita, ho solo dato una scorsa al
codice) sarei orientato a pensare che "con poca fatica" decisamente
non è l'espressione giusta.
bye!