Newsgroup: it.comp.www.php
Titolo: gestionale in PHP

Salve a tutti,
ho avuto un'accesa discussione su it.comp.appl.access
con un tipo che affermava l'impossibilità di
sviluppare gestionali robusti/affidabili/potenti ed efficienti
rispetto ai linguaggi di progr. RAD che troviamo
oggi in commercio...
Qualcuno di voi pensa sia possibile uno sviluppo
di un gestinale serio usando php/postgreesql... ?
Lui accennava l'impossibilità di creare con il php:
anteprime report
/filtri sui dati
/ordinamento on-line dei dati
/tabelle pivot
Secondo il tipo php è destinato solamente ad aplicazioni
di e/commerce...
Vorrei avere qualche vostra opinione..
grazie!
ringo


Di nulla

 <cut> 
beh... secondo me il tizio sbaglia, ma non del tutto :-)
ho sviluppato gestionali sia con interfaccia web (indipendentemente dal 
linguqggio scelto) che come applicativi stand-alone, sfruttando vb ma 
anche borland c++ builder
io credo che un giudizio in valore assoluto non si possa dare, e' tutto 
in funzione delle esigenze.
tra i vantaggi di un'applicativo web-based (php) c'e' senz'altro:
-indipendenza dall'architettura client: basta un pc con un browser e il 
gioco e' fatto
-leggerezza: basta un browser, come gia' detto... non serve potenza di 
calcolo
-delocalizzazione: ovunque ti trovi, se l'applicativo gira su 
intranet/internet, puoi usarlo
*pero'*
-ogni operazione sui dati (o quasi) e' dipendente da un submit di un 
form, o cmq dal caricamento di uno script quindi un timeout, un "pagina 
scaduta" o roba simile puo' essere fastidioso.
-l'interfaccia dell'applicativo sicuramente "perde" qualcosa... niente 
griglie scrollabili con i dati, ordinamenti a video in real time e roba 
simile...
-i drammatici back e forward del browser possono riportarci a pagine in 
cache con dati non piu' coerenti con quelli memorizzati nel db 
dell'applicativo
-i tragici reload: inserisco un nuovo cliente nel gestionale, poi faccio 
un reload... che succede? se l'applicativo non e' scritto bene, se si 
usano i maledetti autoincrementanti come chiavi primarie, se non si 
effettuano controlli sui dati inseriti ci ritroviamo con duplicazioni sul db
*insomma*
io credo che si debba valutare caso per caso, ma soprattutto progettare 
bene l'applicativo e il suo database, senza improvvisazioni!
saluti
g.

 effettuano controlli sui dati inseriti ci ritroviamo con duplicazioni sul
db
Vero, ma se uno non è in grado di evitare cose come queste non penso sia in
grado di creare un gestionale.
-- 
Kluge
1. n. A Rube Goldberg device
2. n. Something that works for the wrong reason.

 grado di creare un gestionale.
anche questo e' vero... in realta' volevo proprio far cedere l'accento 
su questo fatto, facendo passare una velata critica nei confronti di 
free-lance ma soprattutto piccole software-house che commercializzano 
roba *allucinante* :-)
saluti
busettu

 sul db
questi errori vengono regolarmente fatti anche in altri ambienti... 
secondo me dipende dalla programmazione solo al terminale e mai a 
partire dal progetto, non è legato all'ambiente di sviluppo o alle 
tecnologie adottate, per il resto delle osservazioni ho visto gestionali 
che per lentezza o per inusabilità delle interfacce facevano piangere e 
credo che anche qui dipenda da come si fanno le cose.
Ormai con i costi ridicoli dell'HW i servizi/applicazioni web-based non 
sono più così distanti da quelle standalone, forse solo nei casi di pura 
elaborazione c'è ancora della distanza...
Ciao Gianfranzo
-- 
ICQ#: 21258924
Nick Gianfranzo
Home page 
http://www.gianfranzo.it
Gianfranzo è contro la guerra

 ha scritto nel messaggio
news:Vq23b.1081$aG6....@news1.tin.it...

grazie ancora!

 rispetto ai linguaggi di progr. RAD che
unico problema
e non risolto
e' la moddifica dei dati in contemporanea da 2 utenti
ad esempio
3 pezzi a magazzino
utente a vede 5 pezzi ne scarica 2
utente b vede 5 pezzi ne scarica 3
quindi tra i dati visti e i dati reali ci puo essere differenza
questo e' l'unico problema

 questo e' l'unico problema
se non sbaglio si possono fare i lock dei record e gestire in maniera 
transazionale le operazioni su alcuni DB (per esempio se vedi le 
funzioni OCI o IBase)... quindi il problema non sussiste se non che devi 
farti un mazzo tanto, come al solito, per programmare in queste 
situazioni application critical.


 ha scritto nel messaggio
news:biipds$8rulf$1...@ID-155253.news.uni-berlin.de...

Esiste una cosa chiamata "transazioni" con relative proprietà ACIDE, di cui
purtroppo non tutti sanno l'esistenza e/o utilità, nemmeno i creatori di
MySQL fino ad un po' di tempo fa...

 e dove trovare info
Se usi un db relazionale "serio", tipo Postgres/Oracle/Interbase/SQL Server
etc questo ti garantisce che puoi, in soldoni, riunire più query in un unica
transazione.
La transazione, detta velocemente, è l'unità logica di un database per
quanto riguarda le opeazioni sui dati. Soddisfano le seguenti
caratteristiche, dette propietà ACID:
- Atomicità: una transazione viene o eseguita completamente oppure non viene
eseguita affatto
- Consistenza: Una transazione è consistente nel senso parte da uno stato in
cui i dati del db sono consistenti e termina in un nuovo stato sempre
consistente
- Isolamento: L'esecuzione di una transazione non può essere influenzata
dall'esecuzione di altre transazioni (che ovviamente possono essere eseguite
in parallelo)
- Durability (permanenza): I cambiamenti applicati dall'esecuzione di una
transazione devono essere persistenti nel database. I cambiamenti non devono
andare persi a causa di failure
[polemic mode=on]
Il team di MySQL fino ad un po' di tempo fa riteneva fosse inutile
implementare le transazioni, tanto c'era un sistema di locking delle tabelle
alternativo con cui potevi fare le stesse cose... si chiedevano addirittura
a cosa servisse l'integrità referenziale...
[polemic mode=off]
Puoi trovare materiale a riguardo su diversi libri, io ti consiglio
Elmasri - Navathe "Fundamentals of Database systems"
Altrimenti se vuoi qualcosa di più pratico prova a dare un'occhiata su
qualche manuale di Postgresql, e prova a cercare begin, commit, rollback o
abort, penso che dovresti trovare qualche esempio

 [polemic mode=off]
rimane sempre il fatto che tra una lettura dei dati (via web)
e una modifica puo passare del tempo
ad esempio
utente A legge i dati (vengono visti in una form di modifica)
modifica (ore 10.10)
salva (fine lavoro 10.10.15)
utente B legge i dati (vengono visti in una form di modifica)
modifica (ore 10.15)
salva (fine lavoro 10.20.5)
le modifiche di A vanno perse
via web non si pu bloccare il record
(inizia la modifica)
cade la connessione
rimane loccato
(cose che con un applicazione server-clent) non avvengono
in caso di caduta dell'applcazione il sever fa cadere tutti i "loccamenti"
ad esempio i gestionli sono client-server (o monoutente il php va benissimo)
ed avviene uno scambio continuo di dati il browser con php nn lo puo fare
dato che finito lo script, finisce il contatto con il server
il mysql - php non ha una verifica che esista ancora l'utente (ie, netscape)
dall'altra parte


 dall'altra parte
Guarda che i problemi che hai con il web sono gli stessi che hai negli
applicativi normali. La concorrenza (la multiutenza) ci può sempre essere.
L'unica differenza puà forse essere il problema del "refresh" dei dati, cmq
ovviabile entro termini accettabili. Cmq non prendere in esempio mysql, che
ha parecchie lacune, comprese queste.
Se vuoi capire a fondo il problema e come lo hanno risolto, ti consiglio
vivamente di leggere qualcosa tipo Elmasri

 netscape) dall'altra parte
Mai sentito parlare di cookie e/o sessioni ??
Alla prossima.
        MAX

         MAX

 
Nelle FAQ sono spiegate alla perfezione.
Alla prossima.
        MAX
p.s. non so se sono aggiornate anche per la gestione dei cookies, e' un po'
di tempo che non ci metto le mani :((