Newsgroup: it.comp.software.database
Titolo: database per documenti

Salve,
devo gestire una grossa quantità di documenti di vario tipo (doc, xls, jpg,
e chi più ne ha più ne metta...)
e fare una piccola applicazione che li cataloga.
Visto che sono molti (circa 30000 per un totale di 10 GB) e andrebbero
conservati in una serie di cartelle
mi chiedevo se non fosse il caso di memorizzare i documenti all'interno di
un database invece di usare il database solo per il percorso
di salvataggio.
Ora le questioni sono 2:
1) esiste un database che consenta di salvare all'interno dei suoi record
dei documenti (leggi files)?
2) ammesso che si possa fare, quanto è più efficiente salvare i files
all'interno del database rispetto a salvare solo il percorso di
memorizzazione lasciando al sistema operativo l'onere della memorizzazione e
del retriving dei files?
Premetto che l'applicazione dovrebbe girare sotto windows.
Grazie
Ioson


1) Tutti i database (che io conosca) hanno il tipo BLOB. Normalmente 
file binari, di qualunque formato essi siano, non hanno problemi ad 
essere memorizzati in un campo del genere. MySQL ad esempio può andare 
benissimo come scelta.
2) Vantaggi (cito dettagli che sono "veri" per MySQL, ma che molto 
probabilmente lo sono anche per la maggior parte dei DBMS):
- il sistema operativo non deve aprire un sacco di file descriptor per 
accedere ad ogni singolo file che venga richiesto, ma deve di fatto solo 
aprire i file descriptor necessari per la gestione interna del DBMS 
(sicuramente un numero minore). In ogni caso 30000 files se li dividi su 
un numero sufficiente di cartelle non dovrebbero dare grossi problemi; 
bisogna però valutare se e quanto possano crescere in numero.
- se hai directory con molti files può capitare che il sistema rallenti 
per via della gestione più onerosa del file system, mentre con la 
gestione a DB questo problema non c'è
- con i documenti nel DB puoi sfruttare ad esempio la query cache 
(MySQL) con la quale puoi fare in modo che i documenti richiesti più di 
frequente siano interamente in RAM, quindi velocissimi da servire
Svantaggi:
- se cancelli la tabella hai perso tutti i documenti in un colpo solo 
(ma ovviamente questo è facilmente aggirabile con una buona politica di 
backup)
- se vuoi amministrare i contenuti dei campi BLOB non ci sono molti 
buoni client (GUI) che ti facciano vedere in-line il contenuto di un 
documento. Molti lo fanno bene per le immagini (jpeg, gif, png) ma per 
tutti gli altri formati di fatto bisogna "scaricarsi il campo blob", 
"salvarlo come file" e vederselo con l'appropriata applicazione (office, 
acrobat reader, ecc. ecc.)
Altre cose adesso non me ne vengono in mente.

 Ioson
Ciao
Alessandro

 
Si, se usi un database serio.
Per PostgreSQL:
http://www.postgresql.org/docs/8.1/static/largeobjects.html
Saluti  Manlio Perillo

 
http://www.postgresql.org/docs/8.1/static/largeobjects.html
Grazie!
Ma quanto può essere grande un intero database? Parlo di dimensioni su hd.
Per una maggiore fruibilità di molte directory condivise con samba, 
pensavo di portarle su un db e permettere un accesso web, ftp, webdav, e 
chi più ne ha... Insomma, un cms che permettesse più tipi di accessi, 
così in alcuni casi sarà possibile lavorare in locale e sincronizzare il 
lavoro con qualche script.
Via web si vedrebbero anche tutti i dettagli associati ai files (note, 
argomento, revisione), via webdav devo ancora vedere
Sicuramente dovrò trasferire una piccola directory (pochi mega), quindi 
stavo considerando le dimensioni massime per capire quale via fosse più 
"scalabile" nel tempo.
Ciao e grazie
Alessandro

 Ma quanto può essere grande un intero database? Parlo di dimensioni su hd.
Solitamente sono superiori a quelle gestibili dal S.O.
Mi pare che per la 7.4 ci fosse un limite di 64 TB sulle dimensioni di
un database. Probabilmente con la 8 hanno alzato un po' tutte le
limitazioni, anche se adesso non ho un link diretto sottomano.
Bye.
-- 
Alessandro Pellizzari

 
Non saprei, prova a scrivere sulla mailing list di postgresql e chiedere
se qualcuno ha già affrontato il tuo problema.
Saluti  Manlio Perillo

Grazie dei consigli,
Il problema credo lo abbia centrato Corrado e, dopo aver scritto la mail al
newsgroup, analizzando meglio il problema
me ne ero già reso conto.
Finchè i files da salvare sono di tipo conosciuto, o meglio, standard, il
problema di gestirli come record non credo sussista.
Purtroppo, almeno nel mio caso, i files possono essere dei più svariati
tipi... doc, xls, eml, ppt, ecc. ecc.
Certo, si può sempre fare un "passaggio" tramite una locazione temporanea e
poi eseguire l'apertura ma...non è il massimo della vita.
Oltretutto, nel mio caso, alcuni files devono anche essere modificabili.
Probabilmente va fatta una analisi più approfondita e, magari, dividere i
files per tipologia, o per tipo di utilizzo e usare entrambe le tecniche...
Comunque, mi convince il fatto che un DBMS gestisca in maniera più
efficiente una grossa mole di files rispetto al S.O. ( certamente nei
confronti di win e meno in quelli di linux).
Se non altro per evantuali altri scopi di ricerca, statistica, analisi sui
files stessi....
E' chiaro che applicazioni di tipo "archiviazione ottica dei documenti"
usano i DB per lo store dei documenti; hanno a che fare con una solo
tipologia di files (immagini)
ma per una applicazione di tipo più "general purpose" non so....
Grazie

 Solitamente sono superiori a quelle gestibili dal S.O.
8-O  credo sia sufficiente...
Grazie
Alessandro

 Leggi bene la documentazione.
Ahimè, la leggo sempre molto velocemente, e sbaglio di grosso.
Invidio la tua meticolosità nel leggere i sorgenti e la documentazione, 
i risultati si sentono :-)
Ciao
Alessandro

 tipologia di files (immagini)
E non devono nemmeno modificarli
Ciao
Alessandro

 Ma quanto può essere grande un intero database? Parlo di dimensioni su hd.
http://www.postgresql.org/about/
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG


E questo è il vero problema.....
In realtà il modo ci sarebbe...
1) con la mia applicazione recupero il file dal DB
2) lo copio in una dir prescelta
3)la mia applicazione apre una cosa analoga ad un filelistbox che punta alla
dir di cui sopra
4)apro il files da quella posizione tramite la mia applicazione
5) quando salvo (o comunque chiudo), il controllo ritorna al mio programma
che prende il files e lo "rimette nel record" ed archivia
6) finito
Sembra facile eh...
Ciao

 confronti di win e meno in quelli di linux).
A me no...
Casomai è più flessibile, ma più efficiente non credo priorio.
Saluti  Manlio Perillo

 e fare una piccola applicazione che li cataloga.
Naturalmente, hai prima considerato cosa offre il mercato?
Guarda che io ho visto software REGALATO assieme agli scanner che fa
tutto quello che chiedi, assieme a miniature, drag&drop, folding,
stapling, multiutenza e tanta altra roba...
Corri il rischio di produrre qualcosa che flinston vende sul girello
verde ai soliti 49 euri...
Ti potrei raccontare orrori sul buttarsi in un progetto senza le
dovute ricerche di mercato :-(
ciao