Newsgroup: it.comp.www.php
Titolo: per gli esperti di php

Consigliereste l'uso di php per la realizzazione di un applicativo completo
di gestione aziendale?
Grazie

 completo di gestione aziendale?
Si.
-- 
I am what I am, I do what I can
L'uomo, conscio di sbagliare, persevera.



dipende, che tipo di gestionale vuoi fare?
-- 
Danilo

 
Che vuol dire completo?
In linea di massima no, ma dipende da cosa ti serve.
Tac
-- 
"The result is prudent repression and restriction of any free and daring
tendency; constant mortification of impetuous intelligence; unconditioned 
propping-up of imitative and incestuous mediocrity; prostitution of the
great glories of the music of the past, used as insidious arms of offense 
against budding talent; limitation of study to a useless form of 
acrobatics floundering in the perpetual last throes of a behindhand 
culture that is already dead."

Perchè? Lavorare su una grossa quantità di dati può causare dei problemi di
velocità di elaborazione?
Pensavo a un database su mysql. Da quanto so dovrebbe avere ottime
prestazioni sia in termini di accesso che di sicurezza.
Da quello che ho visto di php è dotato di ottimi strumenti e una marea di
funzioni più o meno integrate.
Sto cercando di valutare quale la direzione ottimale da prendere. Grazie.

Completo significa:
Dalla contabilità alla produzione.
Perchè secondo te non è adatto?
Cosa manca al php che per esempio C o Cobol (per citare due dinosauri con i
quali lavoro) hanno?
Sto cercando di fare delle valutazioni sui vari strumenti che ci sono oggi
disponibili.
Grazie.

 Pensavo a un database su mysql.
dai pure uno sguardo a postgresql (
www.postgresql.org
) .... IMVHO molto meglio
del "popolare" MySQL ...
ciao ...
-- 
#include <stdio.h>
int main(void){char c[]={10,65,110,116,111,110,105,111,32,98,97,114,98,111,110,
101,32,60,104,105,110,100,101,109,105,116,64,116,105,115,99,97,108,105,110,101,
116,46,105,116,62,10,10,0};printf("%s",c);return 0;}

Per chi è interessato io ne ho iniziato uno del quale ho già completato
la sezione 'VENDITE' e sto approntando la 'CONTABILITA''
Lo trovate sul mio sito : 
www.devincentiis.it
.
Non mi dispiace affatto se qualcuno lo implementasse con altre
funzioni...
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

dipende dalle dimensioni dei flussi di dati. Per una grossa mole di dati i
sistemi più adatti rimangono ancora
i vecchia ambienti MVS
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.675 / Virus Database: 437 - Release Date: 02/05/2004

ho scaricato il pacchetto, con calma ci do un occhio se non ti secca.

 Sto cercando di valutare quale la direzione ottimale da prendere. Grazie.
Tutto dipende da cosa vuoi fare.
MySQL è ben lontano dall'essere adatto a grandi sistemi informativi, sia in
termini di efficienza che in termini di sicurezza.
E' un prodotto molto valido per basi di dati di medie dimensioni, ma se hai
esigenze più estese ti servono database professionali.
Php offre (forse) strumenti sufficienti a realizzare grandi sistemi
informativi ma la loro realizzazione richiede competenze pluriennali nel
settore delle architetture web.
Considera che il php, pur essendo (forse) "completo" è un linguggio molto
"semplice", e per questo è estrememente difficile realizzare prodotti
robusti, sicuri ed efficienti.
Con il php+mysql puoi sicuramente sviluppare un gestionale completo ma a
seconda dei volumi e dalla sensibilità dei dati potrebbe non essere una
scelta accurata.
Senz'altro è una soluzione economica rispetto ad una architettura
client-server sviluppata ad hoc basata su un db Oracle, però garantisce
livelli molto differenti di prestazioni e sicurezza.

Non ho avuto esperienze molto positive per quello che riguarda Oracle, anche
se stiamo parlando del lontano 96...
Avevo una procedura in AcuCobol. Caricando i dati su un db Oracle (non da
me, ma da chi lo sapeva fare), appunto una enorme mole di dati, lanciando la
stessa statistica scritta da me in cobol e dagli esperti in oracle, nel
primo caso (file Vision) ci metteva meno di un'ora, nel secondo è durata
tutta la notte.
Ora sicuramente le cose sono migliorate ma mi rimane una certa diffidenza è
per questo che avevo pensato a mysql, al di là dei costi naturalmente...
Se dipendesse da me continuerei a programmare in C su linux e con una bella
e pratica interfaccia a carattere, purtroppo i clienti vogliono le cose
'alla moda'...
Non si rendono conto che si fa molto prima a digitare per esempio F4 che
andare a cliccare un pulsante col mouse...
Forse comincio a invecchiare...
Il discorso della lentezza era naturalmente rivolto all'accoppiata php-mysql
non certo al concetto della mole di dati in se.
Grazie dell'opinione, ne terrò conto.

 ho scaricato il pacchetto, con calma ci do un occhio se non ti secca.
No, anzi, spero in una collaborazione con tutti... :-)


 i vecchia ambienti MVS
- Tutto è relativo... se la 'mole di dati' non viene trasmessa 'tutta'
dal server al client e viceversa non vedo dov'è il problema ... :-)



i sistemi gestionali di grandi aziende (fidati perchè è il mio lavoro)
richiedono
trattamento di grossi flussi di dati.
Ci sono ,dove sono io, batch notturne che girano per 4-5 ore e trattano
file con 50 -60 milioni di record...


 trattano file con 50 -60 milioni di record...
Sara' pure il tuo lavoro, ma la tua risposta non ha nulla a che vedere
con quanto affermato da Antonio.


 'alla moda'...
Come qualcun'altro aveva risposto, se sono PMI allora l'architettura web va
benissimo, e per di più è anche molto di moda.
Se invece lavori per una banca o per la pubblica amministrazione forse è
meglio fare un client-server in C++

 con quanto affermato da Antonio.
'nsomma se i dati li invii tutti o un pò per volta poco importa...
la mia modesta esperienza mi ha insegnato che nel gestionale
(io parlo sempre di grandi aziende) poco importa se i sistemi siano
obsoleti (lo sono);quello che conta è che si possano interfacciare
con gli ambienti più utilizzati (es. thema,sap) e che riescano a
far 'girare' batch' lunghe ed elaborate. Senza contare poi che
gli opensource sono (anche se ingiustamente) guardati sempre
di cattivo occhio.


 
Io lo userei, ma non so se posso dichiararmi un esperto.. :-)
Se usi il php salti tutto il lavoro dell'interfaccia grafica, piochè con 
2 righe di html fai + o - tutto quello che vuoi..
Secondo me il tuo problema è più il DB che il linguaggio.. Se usi mysql 
che è veloce e stabile a patto che non gli riversi sopra giga di roba, 
poi usi il linguaggio che vuoi per fare le query. Credo che una buona 
articolazione del DB debba essere appunto il tuo pimo problema.
Se usi il php e l'html, elimini anche il problema dell' installazione 
del programma eseguibile dei terminali poichè basta un semplice browser...

gigi ha scritto:

E' ancora troppo generico.
Al di là di discorsi sulla mole di dati - che ha già fatto Antonio - c'è 
un discorso di interfaccia utente.
Puoi creare un gestionale ottimamente usabile, ma difficilmente sarà 
all'altezza di uno scritto in vb, c o delphi, a meno di non fare i salti 
mortali (tonnellate di flash o js).
Adattandosi alle limitazioni intrinseche delle pagine web (dò per 
scontato che il gestionale lo visualizzerai nel browser) è invece 
possibile costruire un qualcosa funzionante e di tutto rispetto.
Se vuoi autocompletion, lettura on the fly del db senza dover effettuare 
refresh della pagina e roba simile, campi maschera e roba assimilabile 
(features non indispensabili ma alcuni le vogliono).
Questo discorso ovviamente taglia fuori il discorso gtk.
