Newsgroup: it.comp.software.database
Titolo: salvare immagini: per forza blob?

ciao a tutti.
sono nella spiacevole situazione di dover salvare *dentro* al database
un certo numero di immagini. la dimensione complessiva delle immagini
non dovrebbe passare i 700/800mb, quindi niente di preoccupante.
ho letto in varie occasioni il consiglio di tenere il file
direttamente su disco e di salvare nel database soltanto il percorso
del file, ma non capisco, in questo modo, come una query possa
ritornarmi il contenuto del file, cioe' i bytes che rappresentano la
fotografia salvata su server.
se salvando i dati in questo modo una query mi ritorna solo il
percorso la soluzione non va bene, perche' se il motore gira in linux,
il percorso sara' qualcosa del tipo /home/bug/..../nomefile.jpg ed un
client windows che riceva questo percorso se ne fa poco.
visti gli ottimi risultati ottenuti finora lavorando con postgresql su
linux o netbsd, vorrei continuare ad andare avanti con questo db e
pertanto vi chiedo quale sia un possibile modo per inserire le foto in
una tabella di pgsql senza usare il tipo blob. il tipo di dato blob
non e' supportato in modo nativo da questo database e prima di
spendere soldi per comprare un motore db che mi servirebbe solo per
questa "piccola" cosa vorrei essere sicuro di non poter fare
diversamente.
la cosa migliore sarebbe una soluzione piu' indipendente possibile dal
motore db perche' cosi' decidessi di cambiarlo con un altro non avrei
grossi problemi di modifica del codice.
se avete qualche consiglio da darmi, ve ne saro' grato.
ringrazio in anticipo, sperando di non aver detto grosse castronerie.
saluti.
-- 
      Gianni "bugbarbeq" Rondinini, 27+15, RA, 193, 152
   VBR - Vero Birro Romagnolo®, diffidate dalle imitazioni!
 BMW 530D "BatMobile EVO" Driver - Escortone da 500 CV dreamer
Kawasaki "Gas Gas" ZZ-R 1100 - HD Electra Ultra Classic Dreamer
    Contrary to popular belief, Unix *IS* user friendly:
 It just appears to be selective about who it is friendly with

 client windows che riceva questo percorso se ne fa poco.
Ho! Perche', cosa dovrebbe farsene il client Windows? Ottenere il file?
In tal caso usera' ftp o http per prelevarlo dal server. O ancora meglio,
lo fai elaborare da una applicazione sul server ed ottieni solo i dati
gia' processati.
Davide

grossi problemi di modifica del codice.
Piu' portabile di cosi' si muore (unica cosa, invece dell'OID, meglio
se usi un imgid auto-incrementale).
Leonardo
-- 
".signature": bad command or file name

 
Cosi' pero' non ti viene cachata...
Greetings,
Alessandro Trebbi
Pesaro, Italy
http://www.b3soft.com

Cosi' pero' non ti viene cachata...
IMG SRC="image.php/182737464.jpg"
Piu' eventuali headers per gestire il caching a livello di utente o anche
di singola immagine, se mi gira :-)
Leonardo satànio


bene :)
innanzitutto, grazie per le risposte e mi scuso se non ho continuato
il thread prima, ma grazie a 
news.interbusiness.it
 non ne avevo
ricevuta nessuna (ora posto da google).
le vostre proposte sono interessanti ma non sono esattamente quello
che mi serve. cioe' sono soluzioni che mi richiedno di scrivere
un'altra vagonata di codice --forse--. oddio, ora provo a ragionarci:
ditemi dove sbaglio.
provo a spiegare cosa devo fare/sto facendo, visto che non vi ho dato
sufficienti elementi in precedenza.
sto lavorando ad un applicativo per scrivere e stampare libretti di
uso e manutenzione di carrelli elevatori. il libretto e' diviso in
sezioni, ognuna delle quali ha un testo, una tabella (ovvero una
distinta dei componenti di quella sezione) e la scansione di un
esploso. i testi e le distinte le salvo nel db senza problemi. per le
distinte il salvataggio e' banale, mentre per i testi ho scritto un
paio di routine che li manipolano, poi li splittano in chunks di 250
caratteri e poi li salvo come varchar nel database. per estrarre i
testi faccio una select che mi restituisce i pezzi in ordine poi li
metto insieme e sono a posto. i testi sono poche migliaia di
caratteri, quindi il tutto richiede un nientesimo di secondo e la
soluzione nel mio particolare caso e' piu' che buona, anche perche'
gli utenti sono pochissimi, le connessioni "contemporanee" sono
anch'esse pochissime ed il server passa piu' tempo a grattarsi i
piedini della cpu che a fare altro. top sul server difficilmente mi
da' piu' di 0.0%. nel momento in cui l'applicazione andra' su
internet, sara' accessibile solo ad utenti autorizzati, che saranno
molto pochi e la utilizzeranno non di frequente.
non so se e quanto cretino sembri l'approccio dello split dei testi
per il salvataggio, ma a fronte della sua probabile idiozia ha anche
lati furbi, perche' per funzionare richiede solo il driver odbc del
motore a cui mi voglio collegare; inoltre sul server deve girare solo
il db e non e' richisto anche un webserver+php ed il funzionamento e'
indipendente dal db utilizzato perche' e' sufficiente cambiare driver
odbc per collegarsi a qualsiasi db.
per fare i primi test, ad esempio, ora sto usando un file di access.
per i test successivi a volte utilizzo un pgsql che gira in vmware, a
volte un vecchio sql6.5 di microsoft ed il passaggio tra uno e l'altro
e' completamente indolore e si fa in 15 secondi: basta cambiare il
nome del dsn che punta ad un database piuttosto che ad un altro.
comunque dicevo che il problema viene con le scansioni degli esplosi
perche' per quelle non so come fare il salvataggio in modo
conveniente. l'idea era di fare qualcosa come coi testi: salvo su
disco, splitto il file e lo inserisco spezzato come per i testi. ma la
cosa mi piace meno, perche' in un file ci sono tutti i caratteri del
mondo mentre in un testo ci sono solo lettere, numeri, < e >, quindi
sono sicuro di avere problemi nell'inserimento/estrazione dei dati.
se io salvo su disco sul server il file dell'esploso 105604f.gif e
inserisco nel db solo la directory dove ci finisce dentro quel file
devo poi recuperarlo con http/php, come mi indicavate in precedenza.
questo, tuttavia, mi richiede di gestire a manazza la connessione al
server e di utilizzare http, che non e' subito immediato, e di
installare apache+php sul server, cosa che non e' un problema.
mmmmmhh... a dirla tutta, ora che ci penso su avete ragione anche voi:
via internet una connessione al db con odbc non funziona e quindi c'e'
bisogno di passare attraverso php o chi per lui... forse e' meglio
provare subito a far funzionare la cosa in questo modo.
php non l'ho mai usato: ottenere un file su disco e' difficile? e per
gestire connessioni solo da client autorizzati e' relativamente
semplice da utilizzare?
grazie ancora a tutti quanti.
saluti,
gianni rondinini.

 semplice da utilizzare?
Per questo ti conviene usare le facility del Web Server stesso, se
usi Apache (consigliato) e' molto meglio.
Davide

semplice da utilizzare?
No, non è difficle, però se non l'hai mai fatto ti tocca entrare in
un'altra ottica: quella di un'applicazione web.
Se l'applicazione deve essere usata da poche persone, da postazioni
definite e con client definiti, IMHO un approccio client/server classico
può essere la soluzione migliore, perchè ti puoi appoggiare molto anche a
feature del database (sessioni, gestione utenti etc) che ti risparmiano
lavoro. Certo, per quanto riguarda il problema delle immagini non ti sò
dare un grosso aiuto.
Ciao.
Faser
-- 
FABIO SERRA
*Questo testo deve essere valutato secondo il senso della RFC-3*
Per rispondere in e-mail sostituire "invalid" con "faser"
http://www.cfmentor.com
--------------------

semplice da utilizzare?
No; si'.
Leonardo
