Newsgroup: it.comp.lang.visual-basic
Titolo: database testo

ho deciso di convertire e continuare ad usare un db di access in un file
di testo.
visto che posso fare anche a meno dell'sql e poichè le tabelle sono 4 e
i campi per tabella non piu di 30.
i dati nel caso medio dovrebbero essere tre record in una tabella e nel
caso peggiore (esagero abbondantemente) 1500 record in un'altra per ogni
record della prima
ma all'apertura del mio programma dovrò acquisire i dati e renderli
disponibili in delle strutture apposite
domanda: mi conviene tenere le tabelle (cioè gli array di strutture)
quanto più separate possibile o non cambia molto se uso più strutture e
mi simulo le relazioni io? (le relazioni sono solo tra due tabelle)
nel caso peggiore (1500 record) cosa sarebbe meglio in termini di
velocità?
forse che non cambia molto?
buonanotte Valerio

 ha scritto nel messaggio
news:3C16BA91...@hotmail.com...

Io ti consiglio di continuare ad usare il DB.
Come puoi pensare di paragonare le funzionalità e le prestazioni di un
motore DB come il Jet, con l'accesso sequenziale ai file di testo.
L'unico motivo che mi viene in mente è che non ti vuoi portare dietro i 17
MB di mdac in installazione.
SAluti

forse che non cambia molto?
--
Ciao!
Davide

prova a pensare ad xml. ormai la versione 2.0 del core ce l'hanno tutti in
quanto distribuita con ie e ha prestazioni abbastanza buone
ciao
L2K


esattamente e in questa circostanza non ho bisogno della funzionalità di jet

grazie a tutti per aver risposto
comunque la mia domanda non era se mi conveniva ne come esportare i dati ma
come mi conviene gestirli in memoria

ci sono molti programmi che hanno un piccolo database su testo ad esempio:
gozilla, o imesh.
č vero che il gozilla vuole 30 secondi per aprirsi e imesh qualcosa in piu (io
ho 500 dowbloads) ma non mi sembra giustificabile l'uso di jet per una sola
tabella (nel mio caso due) senza nessuna ricerca o funzionalitą tipiche del
database.

 velocità?
La soluzione migliore è crearti dei file ad accesso casuale su disco, con
record a struttura fissa.
Puoi simulare le chiavi di ricerca tramite un semplice algoritmo di hash. Ad
esempio sommi tutti i valori ascii delle lettere che compongono il tuo campo
da indicizzare, e ti salvi per ogni valore l'elenco di tutti gli offset nel
primo database. In questo modo dovresti cavartela in pochi tentativi per le
ricerca con chiave, a meno di casi sfoprtunati in cui ci sono molte chiavi
con lo stesso valore di hash.
Partendo da questa semplice struttura, puoi lavorare come se usassi access
in DAO, con le seek su indici di tabelle, e vedrai che le prestazioni
saranno di tutto rispetto.
Se invece i dati di partanza sono statici, puoi semplicemente tenerli
ordinati sulla chiave di ricerca ed accederci tramite un normale algoritmo
di ricerca dicotomica. Qualche anno fa con questo sistema gestivo una
browselist di qualche migliaio di dati che si mangiava in velocità una
tabella con indice di access 2.
Ciao
*Roby*

Soluzione:
Carichi subito tutto in memoria.
Crei Classi specifiche per gli oggetti importanti. (es classe
prodotto, classe persona ecc)
Crei Una Classe Albero Binario (insieme di prodotti ecc) , conveniente
come ha detto qualcuno per la ricerca HASH o Binaria e ņe operazioni
scrittura e lettura dei file testo.
Istanzi classi di alberi binari contenenti oggetti di tipo persona
ecc. (i tuoi oggetti)
manipoli tutto in memoria , le operazioni di scrittura e apertuta del
file le gestisci nella classe Albero bin... e voli.
Problemi risolti. Velocita' strepitosa.
Limitazioni . Scrivi un sacco di codice non hai l'ereditarieta' ,
template e puntatori (usi il byref) 
Non potendo usare ado per l'accesso al  testo (udl) (per i 17 mb sopra
citati)
ne escludo l'utilizzo. 
Anche se andresti comunque piu' veloce.
Altra alternativa usi VC++.
Massimo Muracchioli 
 

ok grazie e grazie anche a Rice
non so se implementerò una tabella hash o un albero binario di ricerca, ma sono
convinto di buttare tutto in memoria visto che i dati sono pochi. le modifiche
le faccio in memoria e prima di uscire salvo.
a questo punto un'altre domanda:
(io sono un po paranoico) ma se casualmente il file non viene registrato con
successo per un qualsiaisi motivo, o si danneggia? dovrei fare una copia di
backup prima?
ma in fondo un file mdb non ha le stesse, se non maggiori probabilità, di
danneggiarsi di un file di testo? allora perchè mi preoccupo? boh ditemelo voi
ciao Valerio.txt

 wrote:
chiaramente non hai gli stumenti necessari per poter in qualche modo
ripristinare il db come avviene in altri db relazionali o ad oggetti.
(per esempio in access a poco serve)
l'unico problema un po' grosso , visto che sei pignolo , e' quello
dell'accesso concorrente ai file se il prg gira in rete. 
Bloccaggi, accessi contemporanei ad un singolo record ecc. 
In questo caso la congruenza del dato non e' assicurata a 100% , anzi.
Per quanto riguarda il danneggiamento del file sta a te e dipende
dall'harware che disponi. 
Soluzioni:
1) Accesso concorrente VC++
2) sicurezza dati Dischi RAID. e sei trannquillo 
3) la piu' semplice ,prevedi una funzione che copia i file txt in un
"dischetto" e/o contemporaneamente altro utilizzando un algoritmo di
compressione. 
4) Pessima ma integrabile alla 3) scrivi il file con estensione tmp e
lo rinomini. occhio al locking del file 
Massimo Muracchioli


 Bloccaggi, accessi contemporanei ad un singolo record ecc.
no no, non userei mai una soluzione del genere per un database in rete.
sono dati per un programma monoutente e penso che se il file si danneggia pazienza.
gozilla che come dicevo prima funziona così non ha mai fatto cilecca in tre anni
ciao e grazie
Valerio

 dovrei fare una copia di backup prima?
Se sei paranoico, è meglio che lavori direttamente su disco.
E se ti va via la corrente che non hai ancora salvato? E se ti va via la
corrente mentre sei a metà della scrittura del file? Se lavori direttamente
su disco, al massimo perdi un solo record.
Se vuoi fare lo splendido, puoi salvarti per ogni record anche un crc di
controllo, che ti permetta di stabilire se il record è corrotto o meno.
Inoltre lavorare su disco potrebbe perfino risultare più veloce, dato che in
fase di apertura non devi caricarti tutti i record, e in fase di salvataggio
non devi salvarteli tutti. Se poi oggi i record sono pochi, ma domani
diventano tanti, essere partito già lavorando direttamente su disco ti
permette di continuare a funzionare bene senza problemi.
Questa è solo la mia opinione, ovviamente.
Ciao
*Roby*


e certo



guarda che non ci vuole niente a fare un albero binario ne in  vb ne in altri
linguaggi.
Valerio

 
Si lo so che si puo' fare in vb ...solo che redim() , finte classi e 
pseudo puntatori o meglio riferimenti (set) non servono ad un bel niente 
nel tuo caso. 
Bada che le classi si sono potute realizzare non tanto per la pulizia e 
il riuso del codice ,concetto potentissimo ma improponibile senza la 
grande potenza dei linguaggi (direi compilatori) destinati alla loro 
creazione perche' di per se, in termini di efficienza sono una schifezza, 
ovvero non funzionano!!! Troppe chiamate di funzioni.
Pensa semplicemente ai costruttori di copia. Ogni volta che inizializzi 
una variabile , passi parametri e restituisci un valore lo utilizzi e 
sono ben 3 chiamate. Non lo scrivo quasi mai inline ma lasciamo 
perdere....
Tu mi dirai come mai allora esistono ste classi e perche'. Semplicemente 
perche' qualcuno ha inventato un gran bel meccanismo , istruzione, 
statement, chiamalo come vuoi , cioe' "le funzioni inline", che ti 
permettono di riscrivere il corpo (della funzione) al posto della sua 
chiamata (non su di una funzione ricorsiva). Se vogliamo approfondire poi 
ti consiglio un testo. 
In vb non e' cosi'. Non voglio fare il teorico non ne sono capace ...
Torniamo al TUO problema e alla mia , "nostra", competenza visto che hai 
accettato un qualsiasi consiglio dal momento che chiedi aiuto e credimi 
che un albero te lo faccio in vb con tutte le palle che vuoi visto che 
siamo vicino a Natale e ti ci metto anche le lucine.
Mi e' sembrato di aver capito che il tuo fosse stato un problema di 
efficienza.
La provocazione non era rivolta direttamente a te ma alla "pignoleria" in 
senso largo.
Si puo' fare tutto con tutto dipende solo dal tipo di problema che hai 
sotto le mani e che risultati vuoi ottenere a scapito di altro, tempi di 
scrittuara del codice , velocita' ,sicurezza ecc.  
Focalizziamo l'attenzione sul problema.
Visto che il tuo era semplicemente quello di scrivere su di un file di 
testo non mi sarei proccupato piu' di tanto. Bufferizzi e scrivi.
E' chiaro che se hai un file di testo di 8 giga come fai a caricarlo 
tutto in memoria e' assurdo. Cerchi di leggere un pochino di cose alla 
volta , quelle che ti servono, e sei tranquillo ...e' chiaro.
Il sig Roberto ha ragione, crc ecc, ma ha interpretato male ,ovvero non 
mi sono spiegato bene, quello che intendevo dire per non portarsi dietro 
20 mb di ocx e dll varie per il dac .
Non e' detto che debba scrivere su disco tutto il file dopo 12 ore che 
lavori sul programma e salvi solo dopo che esci dall'applicazione (es 1 
record sul file e 100.000 in memoria) , ma con un po' di astuzia appena 
ti accorgi che puoi salvare, lo fai. 
Se vuoi efficienza non usi vb. (parlo della tua efficienza cioe' del tuo 
caso)
Attento non sono qui per osannare altri linguaggi tant'e' che scrivo in 
vb da quando e' uscita la versione per dos e la 1 per win anche se la mia 
voce nei ng si sente di rado. Ci sono nomi ben piu' noti.
Ma il tuo problema e' cosi' banale da non starsi a spaccare la testa 
perche' se ne va via la luce , piove , o a win gli girano le palle. 
Quindi sei libero di fare come credi.
Per me', 1500 record caricarli subito e' un attimo e non mi porrei altri 
problemi neppure della crescita dei dati (in questo caso crei 
un'applicazione a 3 livelli con database distribuiti e te ne fotti dei 17 
o 20 mb del dac). 
Ti crei una pseudo lista, ti ho detto un albero perche' non ti rompi con 
le ricerche, e salvi il file al momento piu' opportuno. 2 ore di lavoro 
... fine. 
Massimo Muracchioli.