Newsgroup: it.comp.lang.delphi
Titolo: Consiglio per DB [Paradox]

Ciao ho sviluppato una applicazione che usa tabelle PARADOX.
Ora mi si presenta il seguente problema: il cliente oltre a inserire campi
stringa (anagrafica) ha la necessità di archiviare files (inviati dai sui
clienti) di diversi formati, txt, word, html,  pdf ecc ecc.
Come mi consigliate di fare?
Chiedere al cliente di salvare i files che di solito gli arrivano in
allegato email in una cartella e poi inserire nel database solo il nome del
file oppure c'e' un modo migliore?
Grazie
   Fabio

 <miyomo<NOSPAM> wrote

c'è un modo migliore ma ti consiglio quello che hai pensato.
Volendo puoi creare una tabella in relazione con la prima contenente magari
il numero del cliente o qualcosa che lo identifica ed un campo di tipo
binario.
Questo campo conterrà il file ( uno ).
Quindi per ogni file appartenente ad un determinato cliente, c'è un record
in questa tabella secondaria.
La cosa è fattibile, semplice e funzionale, ma a me non piace molto. Vedi tu
!! Forse ti servirà un campo per il nome del file, sempre in questa seconda
tabella.
Invece, la tua idea la puoi perfezionare creando una cartella per ogni
cliente, così ti risparmi il nome del file all'interno del database
contenente i clienti ecc ecc...
In questo modo ogni cliente ha la sua cartella con un numero indeterminato
di files. Il tuo programma li tratterà come vuoi tu ed il tuo database non
saprà nemmeno che esistono. Inoltre, al tuo database non interessa sapere
nemmeno il nome della cartella, perchè se sei furbo, gli darai un nome ( poi
sarà il tuo programma a farlo in automatico ) che può essere "generato"
partendo dai dati del cliente. Insomma è il solo programma che si occupa di
questi files e cartelle, mentre il database se ne frega altamente.
Ti saluto....ciao ciao !!
Antonio Tarolla


In effetti avevo pensato anche a questo, ma in effetti non so come infilare
un file (testo,html,word... ecc ecc) dentro un campo database binario...
tanto per confrontare poi le due possibilita'. Potresti dirmi come faresti?
Il file che devo memorizzare e' uno per cliente percio' anche la soluzione
di una tabella ID_CLIENTE - NomeDelFile(stringa) - ContenutoDelFile(binario)
potrebbe essere valida.
Ciao e grazie
      Fabio

Mi sa che LoadFromFile fa al caso mio... no?
Grazie!

 Mi sa che LoadFromFile fa al caso mio... no?
esattamente.....in quella maniera leggi i dati dal file e li assegni al
campo binario.
Insomma come ha anche detto Stefano Tampieri.


file oppure c'e' un modo migliore?
Questo andrebbe bene solo nel caso il file che ogni cliente
manda e' uno solo.  Se e' cosi', fa la cosa + semplice, usa
un campo che identifica il nome del file (magari senza il
path, visto che li salvi sempre nella stessa cartella).
Nel caso i file fossero piu' di uno per ogni cliente, puoi
creare una tabella di relazione intermedia, in cui hai
"codice cliente" e "nome del file" come campi.  In questo
modo, a un cliente possono essere associati + file.
--
CyberWalkie - walkietalkie(at)
libero.it

non fai altro che chiamarla indicandogli il nome del file e fare poi il post
Non capisco perche' memorizzare in un campo blob il
contenuto di un file e non creare, invece, un puntatore al
file esterno.  Secondo me e' preferibile questa seconda
scelta.
--
CyberWalkie - walkietalkie(at)
libero.it

 scelta.
Un mio cliente ha 2000 foto (e andranno a crescere col tempo) da gestire
tramite il mio sofware. Si potrebbero lasciare tutte come singoli file sul
disco, in una cartella, ottenendo un rallentamento pauroso del file system,
dividere in piu' cartelle in modo semiautomatico via software, complicando
notevolmente le procedure del programma e la gestione dei backup/restore, o
metterle tutte in dei blob. Dopo aver adottato le prime due soluzioni,
nell'ordine, ho optato per la terza. Come risultato ho un file da 120 mega,
ma e' 1 file e non 2000. Insomma, dipende :)
Ciao, Sandro

disco, in una cartella, ottenendo un rallentamento pauroso del file system,
Non credo affatto che ci sarebbe un rallentamento cosi'
"pauroso" (anzi), specie per il fatto che questo tipo di
informazione non e' soggetto a gestioni particolari (query,
ecc...).
--
CyberWalkie - walkietalkie(at)
libero.it

 ecc...).
In FAT/FAT32, se devi prendere, nell'ordine il 1999mo file e il 2000mo file
per farne qualunque cosa (aprirli, cancellarli, ecc.) l'handle del file
viene recuperato dal sistema operativo partendo dal 1' file e seguendo la
catena, verso il 2', il 3', ecc. fino a quello desiderato (il 1999mo, nel
caso citato); per leggere il 2000mo si rifa' lo stesso percorso, dal 1' al
2000mo. Come conseguenza di ha un rallentamento progressivo dell'accesso ai
file man mano che il numero aumenta e che le "richieste" si spostano verso
l'ultimo file della catena. Ora, con Win e con le sue cache su disco, il
problema e' sensibilmente ridotto, perche' il tutto passa per la memoria
(mai fatto DELTREE WINDOWS con e senza SMARTDRV sotto dos?), resta comunque
il fatto che allocare 2000 file in una cartella non e' sicuramente una buona
tecnica. Se si tratta invece di pochi file, e magari si sa per certo che non
aumenteranno col tempo, e' ovviamente meglio tenere i file separati dal
database e aprirli a richiesta. In caso di backup bisognera' chiaramente
provvedere a fare il backup dei singoli file, oltre che del database.
Ciao, Sandro

tecnica. 
2000 file non mi sembrano un numero esagerato da gestire.
Secondo me bisognerebbe provare.
--
CyberWalkie - walkietalkie(at)
libero.it

 salti nel disco e' irrisorio.
Temo di non essermi spiegato. Tutte le dir a parte la dir principale, che ha
allocato uno spazio fisso e il cui inizio (e fine ovviamente) e' noto, sono
dinamiche, e cioe' consentono di inserirvi all'interno un numero qualunque
di file. Come conseguenza le voci della directory (voci della directory vuol
dire "header" dei file, non i file stessi) non stanno in uno spazio contiguo
ma sono sparpagliate qua e la' sul disco dove c'e' spazio disponibile. Per
sapere dove inizia, finisce, in che data e ora e' stato fatto un file,
ecc.ecc. il sistema operativo deve cominciare a scorrere l'elenco dei file
dal 1' in lista saltando al 2', ecc. fino a quello desiderato. A quel punto
sapra' in che cluster inizia e di quanti cluster/settori e' costituito il
file, e solo allora potra' iniziare a leggerlo. Per ricostruire l'elenco dei
file e' necessario andare a ripescare le voci dalla directory una per una, e
queste voci potrebbero essere in punti molto diversi del disco, con
conseguente salti di testina da un punto all'altro e una velocita' di
accesso conseguente bassissima. Chiaramente una volta che la cache sul disco
si occupa di tenere traccia in ram della struttura della dir il problema,
dopo il 1' accesso, si annulla o quasi perche' il disco non viene piu'
chiamato in causa e si lavora in ram.
Ciao, Sandro

chiamato in causa e si lavora in ram.
Si lavora sempre in RAM con sistemi come Windows.
Fa qualche prova, se non credi a cio' che ti dico.
2000 file sono una quantita' di dati irrisoria per i moderni
s.o. e i moderni supporti.
--
CyberWalkie - walkietalkie(at)
libero.it