Newsgroup: it.comp.www.php
Titolo: Gestionale GAzie (Open Source)

Un saluto a tutto il newsgroup. Da un po' di tempo ho trovato questo
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

 Stefano
Un sincero in bocca al lupo.

 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/

 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


 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!

 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.

 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!

 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. 

 bye!


 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!