Newsgroup: it.lavoro.informatica
Titolo: Noi si discute sui massimi sistemi dell'ingegneria del software ...

...e poi un mio cliente mi forwarda le specifiche tecniche di un software
che deve acquistare, da $IMPORTANTE$ societ� editoriale italiana e come
architettura leggo "archivio dati su file dbf condivisi in rete"
Mi sono cadute le palle. Non c'� traccia della possibilit� di usare un sql
server qualsiasi.
Siamo nel 2010, non nel 1995, ma forse qualche software house non se ne �
accorta.
PaF

 condivisione e backup/recovery.
Pur condividendo alcune tur affermazioni, esamino: perche' un dbf - o
un file access, o qualsiasi database basato su file, FireBird compreso
- e' sconsigliato in un ambiente distribuito?
-- 
Ciao!
Luca

 PaF
La mia teoria e' che dal 2000 in poi (o al massimo dal 2001) puntiamo
dritti verso gli  anni '30.  Quindi se nel 2010 stiamo come nel 1995 e'
gia' un'ottima cosa. Secondo me dovremmo stare come nel 1990 (o 1992 al
massimo)
Detto questo, se nel 1995 "$IMPORTANTE$ società editoriale italiana" ha
iniziato ad usare dBase e Clipper e ancora i suoi sistemi funzionano in
modo per loro soddisfacente, perche' dovrebbero cambiare ?
Ciao,
Marco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 nessuno aggiornerà nulla...
E allora a che serve? perche' non un banale file di testo / csv / XML?
-- 
Ciao!
Luca

 nessuno aggiornerà nulla...
Ipotizzi male, non entro nello specifico per evitare problemi (inoltre
sarebbe ininfluente ai fini della discussione), ma si tratta di un software
per la gestione di uno studio, con numerose richieste di lettura/scrittura
da parte degli utenti.
PaF

 nessuno aggiornerà nulla...
Posso portare esempio di gestionale largamente usato nella PA che usa
rigorosamennte dbf condivisi in cui vengono quotidianamente inserite
tonnellate di dati. Il bello è che funziona pure.
Il problema del lock è relativo, questi sw vengono usati tutti per
inserimento dati manuale, se trovi i lock e aspetti una frazione di
secondo in più non se ne accorge nessuno. Meno che mai uno statale :)

 E allora a che serve? perche' non un banale file di testo / csv / XML?
Per gestire l'accesso diretto ai record evidentemente, difficile da fare
con un file di testo.

 modo per loro soddisfacente, perche' dovrebbero cambiare ?
Perch� come scritto da Osid, ci sono dei limiti intrinseci in
quell'approccio (prova anche solo a perdere la connessione di rete con un
dbf o mdb aperto...)
Non fraintendere, anch'io sono piuttosto conservativo, qualche giorno fa ho
discusso su un altro ng (per visual basic) con un MVP che sosteneva che
ormai Windows Form � morto e deve essere sempre utilizzato WPF. 
Io sostengo che per quello che faccio Windows Form va pi� che bene perch�
non ha controindicazioni e gli esempi che mi ha postato per convincermi a
passare all'altra tecnologia erano assolutamente insignificanti.
Inoltre Windows Form sar� supportato finch� sar� possibile utilizzare la
Win32 CreateWindow, per cui deduco che per almeno un decennio (ma anche
oltre) il problema non si pone.
Se per� domani scoprissi dei problemi o dei rischi nell'attuale tecnologia
che uso non ci penserei due volte a documentarmi ed eventualmente a
cambiare, fa parte del mio lavoro e dell'impegno che ho nei confronti dei
miei clienti, che voglio siano sempre soddisfatti di quanto hanno comprato
dalla mia societ�.
Un approccio file based era deprecabile 15 anni fa, figuriamo oggi.
PaF

 fare con un file di testo.
Se non ci sono esigenze di aggiornamento, a un file di testo non mi
risulta ci siano limiti di accesso. Potrebbe pure essere in sola
lettura.
-- 
Ciao!
Luca

 secondo in piů non se ne accorge nessuno. Meno che mai uno statale :)
Mi fa pensare comunque a una quantita' di dati abbastanza minima.
-- 
Ciao!
Luca


Beh, si, tra questo modalità e l'altra nella quale si usa un rdbms vero e 
proprio ma  nel db ci sono solo tabelle piatte senza constraint, non c'è 
molta differenza circa l'attendibilità dei dati... :-)))


Beh, non è un caso se oggi non esistono MVP su VB, ASP o prodotti server 
vecchi ma ancora usati...
L'MVP segue sempre le ultime tecnologie MS, altrimenti dura troppo poco :-)

server qualsiasi.
l'$IMPORTANTE$ società editoriale italiana non sara' mica una famosa
per pubblicare un quotidiano su carta colorata e il nome del software
non sara mica di 4 caratteri e comincia per 'S'? Nel caso potrebbe
essere anche peggio di come ti aspetti...
cmq per farti sentire meglio ti racconto questa: l'anno passato
eravamo in predicato di vendere un software ad un nostro cliente, il
quale all'ultimo si e' rivolto ad altra ditta la cui offerta ha
ritenuto piu' vantaggiosa economicamente della nostra.
I sw offerti sono diversi, per piattaforma, interfaccia, db ecc ecc.
Alla fine la curiosita' mi spinge sul sito dell'altra ditta per vedere
un po la demo del loro sw. C'e' una form per chi vuole richiedere
informazioni, la compilo e nel giro di 3/4 giorni mi arriva una mezza
chilata di carta con tutte le brochure del prodotto.
Sul depliant principale (formato cartellina, gommato opaco, apribile
ad albo) nel mezzo spiccano i loghi dei vari MS, Oracle e cosi' via e
la scritta:"Il nostro software lavora con i principali db reDazionali
presenti sul mercato".
la verita', appresa dal cliente, e' che il prodotto utilizza Access
(come db, per le maschere e le stampe)

 lettura.
Ma appunto, chi ti dice che non ci siano esigenze di aggiornamento?
E' ben probabile che ci sia tot gente che deve quotidianamente
inserire ed aggiornare record.

 Mi fa pensare comunque a una quantita' di dati abbastanza minima.
Infatti, probabilmente si tratta di poche pratiche al giorno.
Peraltro, ho anche visto fare data entry massiccio (nel senso di
migliaia e migliaia di entry/giorno) su database *access* condivisi.
E gli ho anche visto fare bum però :)

 PaF
Ciao
M.
-- 
Nessun Bit e' stato maltrattato o ucciso
per scrivere questo messaggio
http://www.qtp.it/Gallery/profile.php?uid=2311

 essere anche peggio di come ti aspetti...
No, č una concorrente.
Quella che dici tu ha fornito il software ad un altro mio cliente, ti dico
solo che il programma fornito funziona *esclusivamente* per l'utente che
l'ha installato, se ti disconnetti e rientri con un utente diverso hai un
bel runtime error ! Per completare il quadretto l'utente deve essere pure
administrator del pc.
Chiaramente per la compatibilitą con Vista e Seven ti attacchi al tram.
Chi l'ha sviluppato ha pensato bene di registrare qualche componente nel
profilo utente e non a livello di sistema...
PaF

Nella mia precededente vita da programmatore ho scritto migliaia di 
righe di codice clipper, (in realt� i primi programmi erano in dBase III+).
Ora ne ho fatto il porting sotto harbour (cambiate una decina di righe 
nel codice) ed � possibile compilare codice clipper per UNA VAGONATA di 
sistemi operativi... questa � la tabella dei compilatori supportati per 
ogni s.o.
Supported <comp> values for each supported <plat> value:
   - linux  : gcc, watcom, icc, sunpro
   - darwin : gcc, icc, clang
   - win    : mingw, msvc, bcc, watcom, icc, pocc, cygwin, xcc,
   -          mingw64, msvc64, msvcia64, iccia64, pocc64
   - wce    : mingwarm, mingw, msvcarm, poccarm
   - os2    : gcc, gccomf, watcom
   - dos    : djgpp, watcom
   - bsd    : gcc
   - hpux   : gcc
   - beos   : gcc
   - sunos  : gcc, sunpro
E' possibile scrivere applicazioni GUI con alcune librerie fra le quali 
una si interfaccia verso Qt e quindi multi-piattaforma....
Un amico ha fatto il porting di applicazioni grandi sotto interfaccia 
GUI senza grandi sforzi (ma dipende da come hai scritto l'applicazione...)
Il progetto lo trovate su sourceforge

> Mi fa pensare comunque a una quantita' di dati abbastanza minima.
Non č detto. I file dbf (che puoi considerare come file con record a 
lunghezza fissa) sono indicizzati (attraverso file esterni) su uno o piů 
campi ed č possibile inserire la clausola UNIQUE.... č quindi possibile 
prevedere un certo numero di indici, con la sola variante che devi 
essere tu a decidere quale usare....
Un altro vantaggio del clipper č quello di avere un compilatore 
all'interno, quindi come nel SQL puoi costruire a run-time le stringhe 
di ricerca....
Conosco gente che ha dbf con milioni di record...


Pensa che ArcGIS, che e' un software di prima classe nel suo ambito e
anzi..in pratica e' il software GIS commerciale per antonomasia, usa
la stessa architettura da 15 anni e si appoggia su file dbf.
In effetti, e' un software pieno di problemi...
Cmq, quella societa' editoriale italiana che archivia i dati su file
dbf probabilmente e' quella di Luc?

 dbf probabilmente e' quella di Luc?
No assolutamente.
In quanto ad ArcGIS, non lo conosco ma ho utilizzato programmi simili, come
QuantumGIS e uDig e a livello di facilit� d'uso non mi hanno entusiasmato,
tanto da farmi venire una mezza idea di scrivere uno pseudo Paint su base
dati PostGIS...peccato non ne abbia il tempo :-(
E' un settore dove c'� margine di sviluppo, trovo curioso che per esempio
non ci siano utilities open source che permettano di esportare facilmente
una mappa in PostgreSQL/PostGIS in DXF, il programmino me lo sono dovuto
sviluppare da solo (il contrario DXF -> PostGIS si, ma se vedi il codice
altro che fisolofeggiare sugli If...)
PaF

 Conosco gente che ha dbf con milioni di record...
Ma per carita', se la cosa e' efficiente e funziona, perche' no. L'ho
detto mille volte, lo strumento assoluto non esiste.
Il problema e': supponi di dover fare interrogazioni pesanti su quei
milioni di record; in questo caso, sei d'accordo con me che intasi a
tappo la rete, se non ha un sistema corretto, che fa l'interrogazione
giusta e che risponde con la quantita' di dati giusta (che poi, guarda
caso, e' cio' che fa un DBMS)?
Poi, ho visto di recente follie del tipo: accedo a SQL Server, carico
TUTTA una tabella in memoria locale ("select * from...") e poi scorro
le singole righe con un loop per avere solo i dati che mi servono!
-- 
Ciao!
Luca

 impiego se c'è questo tipo di concorrenza...
ti viene da pensare male..
ci sono aziende a cui non frega un tubo di come è fatto il programma, 
basta che funzioni.. ergo tra te e chi ha scritto quella bestialità non 
c'è, ai loro occhi, alcuna differenza..
S.

 c'è, ai loro occhi, alcuna differenza..
E' vero, però non tutti i clienti hanno le fette di prosciutto sugli occhi,
per fortuna oserei dire.
PaF

 le singole righe con un loop per avere solo i dati che mi servono!
Hai mai visto una query schedulata ogni minuto ma che dura due minuti 
perché si sono "scordati" di mettere un indice e fa una full-scan... DUE 
minuti invece che millesimi di secondo... una cpu al 100% per colpa di 
braccia rubate all'agricoltura...

 le singole righe con un loop per avere solo i dati che mi servono!
Ahhhhhh ne ho vista una così anch'io, solo che invece di essere una
sola tabella, era una join di N tabelle!
Poi venivano a dire "ma com'è che eseguendo un'operazione si blocca
tutto"...
(perché oltretutto le tabelle, giustamente, le lasciavano APERTE e
bloccate per gli altri fino al termine dell'operazione, visto mai)


Quoto.
Diciamo che pero' lo hanno abbastanza clienti da permettere di 
proliferare anche ai meno "smart", che comunque inquinano il mercato 
degli altri...


la stessa architettura da 15 anni e si appoggia su file dbf.
BOOOOOOM!! Ogni tanto bisognerebbe documentarsi prima di parlare.
io mi occupo proprio di GIS e in particolare proprio di ArcGIS, e ti posso 
garantire che l'architettura negli ultimi 15 anni è stata stravolta e non ho 
mai usato file dbf. Semmai si possono usare shapefile per l'interscambio di 
dati, ma prevalentemente si usano database geospaziali che si appoggiano su 
tutti i dbms più diffusi: sql server, oracle, postgres, db/2.
Che ci siano ancora dei problemi è vero, d'altra parte mi rendo conto che la 
complessità della memorizzazione e trattamento di dati spaziali è molto 
superiore a quella dei semplici dati tabellari, e c'è ancora della strada da 
fare. 

 - e' sconsigliato in un ambiente distribuito?
Non è che è sconsigliato a priori, ma la più grande controindicazione è che
se l'accesso e la manipolazione dei dati sono effettuati usando il paradigma 
del set di dati (SQL ad esempio)
le operazioni di I/O necessare a creare/gestire  il set di dati (leggi 
lettura/scrittura dei singoli record e delle tabelle temporanee di lavoro 
per eventuali group by/order by) debbono essere fatte dal singolo cliente 
facendo transitare quantità enormi di dati sulla rete. Ad esempio una 
operazioni di aggregazione su di un db file shared richiederebbe il transito 
sulla rete di tutti i record della tabella a fronte del transito sulla rete 
della sola richiesta e del solo risultato di un sistema Client/server vero. 
E credo che questo già basti.
 

 questo già basti.
OK. Ma l'esamino non era per te... ;-)
-- 
Ciao!
Luca

 occhi, per fortuna oserei dire.
Sempre nella pubblica amministrazione e' pieno di SQLserver e di Oracle 
perche' un "responsabile del sistema informativo" (o informatiCo) che parla 
per sentito dire ha preteso un prodotti che tiene i dati in un "database 
relazionale". Risultato: l'ente oltre alla licenza del software paga anche 
la licenza per un databse del genere, e poi vai a vederlo e scopri che
a) si accede con usedID/pwd "sa" "sa"
b) la struttura dei dati e' identiche a quella dell'applicativo prima di 
passare al db
c) ogni operazione apre tutte le tabelle necessarie con un "select * 
from..." e poi l'applicazione lavora con dei dataset pesanti una tonnellata
d) il server non regge il dbsm e devono aggiornael o addirittura cambiarlo
Forse, in un piccole ente locale, e' davvero meglio trovare dei file di 
testo che un dbsm
-- 
  Vilco
And the Family Stone 

 (come db, per le maschere e le stampe)
Perche' usano ODBC/OleDB e quindi l'utente puo' scegliere il rdbms che 
preferisce. Il vostro ha il braccino corto, o ignora cos'e' access, e ha 
scelto la versione piu' economica. Scommetterei l'autoradio che c'e' la 
possibilita' di usare SQL o Ora, a volerli


Luca Menegotto wrote:


Fai una bella ricerca di un record specifico su un grosso file di testo, poi 
mentre quella gira fai una seek pressoche' istantanea su un grosso dbf 
(ordinato opportunamente). Non per niente viene proprio da li la tecnologia 
rushmore.


 un grosso dbf (ordinato opportunamente). 
La differenza tra un file di testo e un DBF e' l'indicizzazione. Nulla
piu', nulla meno (nota peraltro che ricordo vagamente che un tempo i
files DBF erano in formato testo).
A parte il fatto che a suo tempo ho scritto anche files di testo
indicizzati (caricato l'indice, il dato veniva raggiunto in modo
istantaneo, dal momento che bastava aprire il file e fare una fseek),
la questione non era files di testo vs/ dbf, era dbf vs/ dbms.
-- 
Ciao!
Luca

 la questione non era files di testo vs/ dbf, era dbf vs/ dbms.
Ma anche di dbf vs testo: "E allora a che serve? perche' non un banale file 
di testo / csv / XML?"


 di testo che un dbsm
O forse sarebbe da sparare ai SysAdmin... ;-)
SQL Server in versione Express gira tranquillo sul mio schifosissimo PC
di 4 anni.
E ci sono alternative valide (Postgres)...
-- 
Ciao!
Luca

 E ci sono alternative valide (Postgres)...
Infatti stanno cominciando a comparire anche loro, sia postgres che mysql.


> nessuno aggiornera nulla...
Ora, tu la vedi una base dati di qualche decina di mega a cui nessuno
aggiorna nulla? Io no. E anche se fosse, meglio un bel DBMS che mi
evita una bella quantita di round trips.
-- 
Ciao!
Luca