Newsgroup: it.comp.lang.delphi
Titolo: Immagazzinare immagini in un database

Devo memorizzare su un db delle foto con descrezione e relativi 
commenti. Le foto sono tantissime, ne arrivano una cinquantina al 
giorno, quindi immaginatevi in un anno quanti record finiscono nella 
tabella.
Se decidessi di salvare le foto in un campo blob, cosa succede a basso 
livello? Il motore del db conserva fisicamente nel record una 
rappresentazione binaria della foto, oppure si limita a salvare la foto 
da qualche parte e a linkarla nel record?
MT

MT ha scritto:


QUALE DB?
Cosa si puo' rispondere alla tua domanda se non indichi quale DB usi o hai
intenzione di usare?
Ciao
ACSH
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 da qualche parte e a linkarla nel record?
Paradox per i campi memo/blob usa un file a parte con lo stesso nome della
tabella (cambia solo l'estensione che però non mi ricordo, forse .dbt) però
tutte le immagini finiscono sullo stesso file.
Ai tempi di dbiv questo metodo aveva un problema: il file cresceva a
dismisura in quanto quando veniva cancellato il testo da un memo lo marcava
solo come cancellato, ma non recuperava lo spazio, il clipper aveva un
programma apposta per compattare i dbt che copiava semplicemente tutti i
recor da una tabella all'altra e cancellava la vecchia.
SQL server, li memorizza fisicamente all'interno di un unico file .mdf
assieme a tutti i dati, logicamente sul record della tabella tine un
puntatore ad un'altra parte dove è memorizzato il file.
Quello che puoi fare è creare un altro data file, a questo associare un file
group e poi la tabella la associ a quel file group.
A quel punto, quando crei il data file puoi anche metterlo su un altro
disco.
Gli altri database non so come lavorino.

 intenzione di usare?
Il DBMS è MySQL. Pensavo (forse erroneamente) che più o meno tutti gli 
engine utilizzassero a grandi linee lo stesso sistema. Grazie,
MT

 puntatore ad un'altra parte dove è memorizzato il file.
Il mio DB è MySQL. Se funziona come SQL Server, allora non dovrei avere 
problemi nelle query, vero? Nel senso che l'engile del DB *prima* esegue 
la query (solo sulle informazioni alfanumeriche) e solamente dopo, 
quando scorro il dataset risultante, mi carica via via le immagini. Giusto?
MT

 
Consiglio a prescindere salva su db il percorso all'immagine e 
l'immagine in una cartella. Molto meglio per la vita del db. Unico 
difetto non puoi usare un data-aware in questo modo.
Omega

 difetto non puoi usare un data-aware in questo modo.
Infatti questo è il metodo che ho usato sempre per le applicazioni 
locali. Ora, invece, tutto quello che so è che il database server si 
trova all'indirizzo ip 207.145.93.190 (naturalmente questo numero è 
inventato).
Non so se sulla macchina che ospiterà il database server sarà possibile 
installare un server ftp o cose del genere. Quindi pur volendo 
memorizzare nel db il percorso dell'immagine sul server, come spedisco e 
ricevo le immagini?
Ci ho pensato a lungo, avevo persino pensato che presumibilmente una 
macchina che ospita un server mysql debba avere anche un server ssh, 
così che possa usare scp per inviare e ricevere le immagini... ma non ho 
la sicurezza al 100%. Per cui l'unica strada percorribile è memorizzare 
le immagini direttamente nel record e poi se la vedono i componenti di 
accesso ai dati a trasferire le immagini.
Naturalmente se vi vengono altre idee vi sarei infinitamente grato...
P.S.:
Però adesso ho notato una cosa: quando scorro il dataset, le immagini 
che appaiono nel componente DBImage vengono visualizzate troncate (nella 
parte superiore compare un rettangolo nero). Sto cercando con Google... 
possibile che non me ne vada bene una?!
MT

 gli engine utilizzassero a grandi linee lo stesso sistema. Grazie,
Rispondo senza aver letto il resto dei post, quindi possa darti una 
indicazione superata.
Le mie conoscenze sui DB sono superficiali, e di MySQL non so quasi 
niente. Detto questo,
se sei "costretto" ad usarlo, salva solo il path dell'immagine nel DB 
e lascia gestire al
SO l'immagazzinamento del file dell'immagine (sicuramente lo fara' 
meglio di questo DB,
soprattutto se instalatto su versioni NT, 2000 e XP con gli adeguati 
file system). Se puoi scegliere,
buttati su un SQl server serio e lascia gestire tutto a lui.
Tutto IMHO.
Ciao.
ACSH 

 difetto non puoi usare un data-aware in questo modo.
Ho avuto a che fare con una app delphi che usava M$Sql che lavorava in 
questo modo....
I tempi di risposta, all'aumentare delle immagini diventarono talmente 
lunghi da costringere ad un refactroring...
Certo, si puo fare, ma a patto di non mettere tutte le immagini nella 
stessa cartella; ma in questo modo la gestione dei files delle 
operazioni sui files si complica...
-- 
Alberto Salvati
A NEAPOLITAN Delphi Developer who is studying c# and .net
"Dicette 'o pappece 'nfaccia 'a noce dammi 'o tiempo che pure te spertoso"

 quando scorro il dataset risultante, mi carica via via le immagini. Giusto?
Cosa vuol dire "prima" e "dopo"? Se scrivi:
SELECT CAMPOCHIAVE, CAMPOTESTO, CAMBOBLOB FROM TABELLA WHERE CONDIZIONE=TRUE
il cursore ti restituisce i 3 campi e se ne frega se sono int, char, 
varchar, blob...
Non ho mai avuto la sfortuna di usare MYSql,  quindi ti passo alcune 
dritte + generiche...
1) Se il tuo server è windows e non ti secca suddividere le immagini su 
+ cartelle, allora puoi salvare nel db solo path+nomefile+estensione, ma 
ti suggerisco di normalizzare, avendo 3 campi diversi:
path
nomefile
estensione
Pensa cosa potrebbe succedere se, x un motivo qualsiasi, devi spostare 
file su altre cartelle è il percorso non è separato.
Per evitare ridonndanza, i nomi delle cartelle dovrebbero essere salvati 
come Id che puntano ad una tabella nella quale un path sarebbe presente 
una ed una sola volta.
2) Se il tuo server è windows e TI SECCA suddividere le immagini su + 
cartelle, allora le salvi in un campo blob; ovviamente, se sono tiff o 
bmp, ti conviene comprimerle, e magari aggiungere un campo nel record 
che ti dice se il contentuo del blob deve essere scompattato prima di 
essere utilizzato. Questo x evitare di comprimere un formato gia 
ottimizzato come jpeg.
3) Se il tuo server non è Windows, non so dirti cosa conviene: dipende 
dalle caratterisctihe del file-system.
4) Su M$Sql, se una tabella include un blob, le query su di essa 
risultano + lente rispetto a quelle fatte su una tabella identica salvo 
il campo blob. Suggerisco un test rapido su MYSql
5) Su Interbase 6.x la dimensione del blocco di un campo blob è in 
funzione della dimensione della pagina del db: + è alta la dimensione 
della pagina + è grande in blocco dei blob. Non so se MySql ragiona 
nello stesso modo, ma controlla prima di avere sorprese strane per 
l'occupazione di spazio su disco.
6) Se puoi, molla i giocattoli e usa un *database*.


 
Non hai bisogno ne di server ftp ne di server ssh. Devi scrivere una
applicazione su piu livelli.
Scenario: un server affacciato su internet con ip pubblico che sta in
ascolto su di una porta che tu decidi (es la 4235)
Su questa porta rimane in ascolto una applicazione (il livello intermedio)
che prende in carico le richieste di dati, le elabora e le passa al db,
pesca le immagini in locale dal server e ti rimanda indietro un flusso di
dati che contiene sia le informaizioni da te richieste presenti sul db che
le immagini.
A questo punto sul client i dati li gestisci come meglio credi.
Scenario: server dedicato con db e storage per le immagini.
Se compatibile con le policy di sicurezza aziendale mappi via rete la
cartella che contiene le cartelle con le relative immagini, e passi questa
unità logica piu il percorso e il nome dell'immagine mappata al Timage
che leggerà l'immagine via rete. E' la soluzione piu semplice, se le
metti nel db e poi ti si impenna il flusso di dati da immagazzinare,
rischi di far scoppiare il db se non è ben strutturato. Attualmente sto
lavorando nel campo dell'archiviazione ottica per la (credo) piu grande
società italiana. La soluzione di memorizzare le immagini su filesystem
è la piu conveniente. Ciao f
-- 
====================================
Coltiva linux, che tanto windows si pianta da solo!
Linux registered user: 364664 (
http://counter.li.org
)

 stessa cartella;
lo credo, anche perchè i filesystem di casa ms non riescono a contenere
oltre un certo numero di oggetti per cartella.... considera quanto sono
fatti bene!! mi è capitato su una cartella che se non mi sbaglio aveva
circa 150k di oggetti al suo interno (non cartellle) e non dava
possibilità di vedere gli oggetti presenti al suo interno!
ciao f


 una ed una sola volta.
se hai cartelle con un solo nodo questa struttura ti va bene, altrimenti
devi prevedere una struttura padre figlio dentro la tabella con ricorsione
per la scansione dei nodi....


 per la scansione dei nodi....
oddio, io sono x una normalizzzazione estrema, ma questo lo vedo 
eccessivo. Non creerei una struttura ad albero, che mi costringe poi a 
molte query per rcostruire il nome del file completo di percorso.
