Newsgroup: it.lavoro.informatica
Titolo: [OT] immagini memorizzate nel database

...tecnica che non ho mai usato
(utilizzo sempre link a file esterno al db).
 
 
Attualmente vedo la Canistracci srl  ( di livello tecnico IMO  non elevato)
 incontrare svariati problemi nell'inserimento/aggiornamento di immagini nel 
db.
 
Riferendosi a siti di e-commerce aziendali (no sitarello della pizzeria),
... pro e contro di questa metodologia?
 
Vs esperienze?
 
 
TIA
 
 
ciao
fm
 
 

 pizzeria), ... pro e contro di questa metodologia?
 
pro: ricerca/indicizzazione, performance sui grandi numeri, replicazione 
e alta disponibilità in base alle caratteristiche del database.
contro: maggiori difficoltà a gestirli a mano.


Ricerca e indicizzazione penso sia sui metadati, non sulle immagini in se
 
  ngw

 Ricerca e indicizzazione penso sia sui metadati, non sulle immagini in se
 
si naturalmente non intendevo ricerche nel contenuto bitmap. 


Magari sbaglio ma penso l'OP intenda salvare fisicamente il file nel DB.
Se e' quello il caso, direi che e' molto molto meglio evitare, i DB sono per dati
strutturati, non per blob di dati.
 
  ngw

 strutturati, non per blob di dati.
 
si si, è corretto, io intendevo proprio il confronto fra salvare il file
sul db (campi blob, gridfs, datastore o simila) rispetto al file system.
la ricercabilità mi riferivo alla ricercabilità dell'immagine stessa a 
partire dai dati indicizzati sul db, es. cercare l'immagine di un certo
articolo in un certo formato. chiaro che il db può mantenere anche solo
il riferimento al file e funziona identico ma sono comunque due tecniche a mio
avviso che hanno i loro pro e i loro contro. nessuna delle due la battezzo
sciocchezza tout court, per intendersi... poi nel caso specifico non 
discuto.
 

 per dati strutturati, non per blob di dati.
 
e in SQL i tipi BLOB, CLOB etc allora che ci stanno a fare ? :)
 
diciamo che, come per quasi qualsiasi soluzione nell'informatica, ci sono 
vantaggi e svantaggi
 
-- 
Soprano


per mettere le fatture, in formato in pdf  :)
magari 1000 fatture a pdf, da indicizzare
 
e ti toglie il pensiero di "spostare" le fatture per sempre,
beh lo so' questa e' un po' criptica :)
 
felice pago
 
.


Puoi mantenere i metadati e usare una convenzione per il naming, non c'e' motivo per
mantenere il file stesso nel DB.
Se hai tutto sul FS, o ancora meglio su uno storage terzo come ad esempio S3, hai una
soluzione che costa pochissimo, molto piu' facile da distribuire (anche senza cloudfront),
e che mantiene tutti i vantaggi dell'uso del DB.
 
  ngw

 e in SQL i tipi BLOB, CLOB etc allora che ci stanno a fare ? :)
 
Forse non è questo il caso, ,ma magari tali tipi li hanno fatti e
subito hanno imprecato, deprecandoli :-) L'informatica è pure piena di
pseudo-standard fasulli, buttati nella monnezza 10 minuti dopo essere
stati lanciati in pompa magna.
 
 

 e che mantiene tutti i vantaggi dell'uso del DB.
 
Su servizi come S3 non so. Ma se hai tutto su un file system locale
del server, non c'è paragone tra mantenere migliaia di file singoli
(parlando di applicazioni di un certo impegno)  piuttosto che un
database. Specialmente se questi files immagine non sono statici, ma
sono generati dall'applicazione. Basta pensare a quanto diventa
complesso gestire un "semplice" rollback in caso di qualche errore
elaborativo di un processo batch, che ti ha creato centinaia o
migliaia di files (es. proprio una fatturazione di massa).
Ma si potrebbe pensare anche ad altro, ad es. all'allocazione fisica:
quella del file system è efficiente tanto quanto quella del db? Nel
senso di ottimizzazione spazio e velocità di recupero dell'immagine.


ci sono tanti motivi per i quali può avere senso salvare degli oggetti 
binari in un database, me ne vengono in mente:
 
- l'oggetto stesso partecipa alla transazione, in caso di rollback è il 
database che ripristina la situazione precedente
 
- l'oggetto segue le regole di cascade impostate nel database
 
- è molto più semplice tenere sincronizzati gli oggetti con i riferimenti 
ad essi
 
- l'oggetto non ha un nome da mantenere, non è sottoposto ai diritti di 
accesso sul file system, ma a quelli di accesso al database
 
- se fai un backup del db automaticamente lo fai anche dei relativi 
oggetti binari
 
- puoi usare funzioni preimpostate del db, tipo "select unzip(colonna) 
from table"
 
naturalmente ci sono anche i contro: più spreco di memoria dedicata al 
database, operazioni di lettura/scrittura meno performanti, costo dei 
dischi dedicati ai database generalemnte più alti ecc.
 
 
-- 
Soprano

 migliaia di files (es. proprio una fatturazione di massa).
 
Curiosita' mia personale:
 
a me capito' nel lontano 2001 di dover inserire delle immagini in campi
BLOB di un DB. Quello su cui lavoravo io era un semplice sito per fare una
specie di catalogo online di un calzaturificio, ma la stessa tecnica
volevano poi usarla per un prototipo (sul quale avevo iniziato a lavorare)
per un sistema abbastanza piu' complesso che sarebbe dovuto servire alla
Piaggio per informatizzare l'ufficio acquisti (nel prototipo il DBMS era
MySQL, nel sistema reale avrebbe dovuto essere Oracle). Solo che nel caso
del sistema per la piaggio, almeno quando si fosse passati dal protoripo
al sistema reale loro volevano inserire come BLOB non tanto delle immagini
tipo jpeg o simili, ma volevano inserire dei file generati da autocad,
quindi dei disegni meccanici e roba simile; All'epoca ogni file di questo
genere "pesava" varie centinaia di mega (oggi non saprei). Considerate le
capacita' dei DB di allora e il numero di file autocad generati da
un'azienda come la Piaggio, questa agli ing. informatici che lavoravano al
progetto sembrava un'idea piuttosto folle (quella di tenere nelle tabelle
del DB dati del genere).
 
Non so dire come abbiano risolto, visto che io me ne andai praticamente
quando era appena stato iniziato il prototipo.
 
Pero' volevo capire se oggi come oggi, cioe' 13 anni dopo la mia
esperienza, qualcuno andasse da un DBA e gli dicesse:
 
"ho bisogno di un DB che mi consenta di memorizzare direttamente in
tabella come blob, alcuni file binari, ciascuno dei quali e' grande
qualche centinaio di mega e ogni giorno l'azienda produce decine se non
centinaia di questi file che devono essere inseriti del db."
 
Cosa direbbe il dba ?
 
 
 
Ciao,
Marco.
 
-- 
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it
 
 
 

 senso di ottimizzazione spazio e velocità di recupero dell'immagine.
 
premesso che, ovviamente, non ha senso fare un confronto tout court fra 
questi due metodi di memorizzazione, si presuppone che se uno si pone il 
problema è perché 1) ha un database e 2) ha delle informazioni sul 
database come minimo da tenere collegate al file (e viceversa). ora 
converrai che avere la possibilità di gestire gli aggiornamenti del file 
binario e dei suoi dati in modo transazionale nonché di avere un legame 
"indissolubile" fra questo contenuto e i suoi dati non sono vantaggi da 
poco. ma anche la semplificazione della gestione della sicurezza. insomma 
è chiaro che sono tanti gli aspetti da valutare ma i vantaggi ci sono.
 


Grazie a tutti quelli che hanno risposto   !!!
 
ciao
fm
 
 

 quindi dei disegni meccanici e roba simile; 
 
In pratica una qualche forma di PDM, i PDM usavano ed usano sempre un Vault esterno per la gestione dei file, in pratica un'area dl File System gestita direttamente dal DB mediante opportune procedure.
 
Alcuni DB hanno funzioni native per gestire questa cosa, in altri lo si fa via SP, in ogni caso nel caso di file di quelle dimensioni è la cosa migliore.
 
Ciao
  Francesco

 dischi dedicati ai database generalemnte più alti ecc.
 
Su questo sono d'accordo, potenzialmente un dbms è specificatamente
progettato per ottimizzare tutte le operazioni di gestione dei dati.
Anche dal punto di vista dell'I/O fisico potrebbe essere che il db lo
sfrutta meglio.
Poi se tutti questi vantaggi potenziali trovano piena attuazione nella
pratica non l'ho mai sperimentato.
Addirittura mi sembra che certi tipi speciali in certi db (purtroppo
non ricordo quali) mantengono automaticamente dei singoli files come
se fossero dei campi, quindi unificando i due approcci.
 


Centinaia di mega per singolo file mi sembra veramente tanto da
gestire entro un singolo campo di db; magari con una compressione si
ha una riduzione significativa. E' anche vero che oggi una cosa simile
si verifica, ad es., con i file video. Esattamente quello che fa
Youtube e gestori simili.

 è chiaro che sono tanti gli aspetti da valutare ma i vantaggi ci sono.
 
In sostanza mi sembra che siamo d'accordo, potenzialmente meglio avere
tutto entro il db. Salvo successive analisi e verifiche del caso
effettivo.

 fossero dei campi, quindi unificando i due approcci.
 
PostgreSQL offre supporto per i "Large Objects".
In pratica memorizzi l'Oid del file, e poi i dati sono salvati altrove in 
chunks da M kb (e viene fornita un API apposita per gestirli).
 
 
Ciao  Manlio

On 9 Mag, 15:31, Manlio Perillo <manlio_perill...@SPAMlibero.it>
wrote:

e un backup/storicizzazione come funge ?
 
 
felic epago
.

 chunks da M kb (e viene fornita un API apposita per gestirli).
 
Lo fanno anche Oracle e MySQL.
 
M.

 Lo fanno anche Oracle e MySQL.
 
Anche MS SQL Server sia con gli RBS sia con il FILESTEAM
 
Ciao
  Francesco


Con altrove, intendevo in una tabella di sistema, che contiene le colonne:
 
 Column |  Type   | Modifiers 
--------+---------+-----------
 loid   | oid     | not null
 pageno | integer | not null
 data   | bytea   | 
 
Il backup, quindi, funziona normalmente.
 
 
 
Ciao  Manlio


nel posto in cui ho lavorato fino a poche settimane fa qualche
volta mi è capitato di sviluppare web applications in cui
erano previste delle sezioni nelle quali c'era la necessità
di memorizzare un'immagine.
 
Qualunque fosse il db utilizzato per la webapp (per lo più
mysql e sql server), noi procedevamo in questo modo:
per prima cosa definivamo il percorso, ossia la (o le)
directory, in cui dovevano essere messe fisicamente le
immagini (non ho voluto scrivere "uploadate", lo so che si
usa così, ma a me questi termini fanno davvero cagare il
cazzo, per cui cerco di non usarli, a costo di usare
lunghe perifrasi). Per definire il percorso, di norma
si andava nel web.xml a mettere una variabile contenente
la stringa del path, in modo che la si potesse poi
chiamare agevolmente e gestire in un unico punto, anche se
mi pare che qualche volta invece il percorso lo
avessimo definito nella classe java in cui si faceva l'upload.
 
Poi, una volta definito il percorso, nella classe java (la
servlet) facevamo l'upload dell'immagine presa dall'input
file della jsp, e nello stesso metodo si faceva la insert
sul db del nome dell'immagine.
In sostanza:
 
 
public void salvaImmagine()
{
    eseguiUpload();
    salvaNomeImmagineSulDb();
}
 
 
 
questo era in genere lo standard. Se poi si voleva togliere
l'immagine memorizzata, semplicemente si faceva la delete
su db, ed eventualmente la cancellazione fisica del file
(ma non necessariamente).
Poi ovviamente nell'eseguiUpload() se necessario facevamo
altre operazioni, tipo cambiare il nome dell'immagine in
base alle esigenze del progetto stesso (ed è successo
più di una volta, che ne so, mettere la data, o mettere
un id di qualche oggetto, ecc.), e salvando poi
ovviamente su db col nome corretto.
 
 
E' chiaro che questo approccio non è perfetto, perché
in pratica, come puoi vedere dallo schemino, tu devi
fare un'unica operazione (salvare l'immagine) e la 
trasformi in due operazioni, cioè upload e salvataggio
su db, per cui può benissimo accadere che una va a buon
fine e l'altra no, cosa che naturalmente non è buona.
 
Con un po' di gestione eccezioni io cercavo di limitare
il rischio, ma d'altra parte se hai due operazioni invece
di una si sa che un po' di rischio rimane.
 
 
 
 
Però sinceramente devo dire che a me questo approccio
sembra buono, naturalmente in base alle conoscenze che
ho io: una volta mi è capitato di vedere invece un db
(non ricordo che tipo) in cui proprio si memorizzavano
i bit dell'immagine, ma a me sembra una cosa inguardabile,
così.
 
L'immagine non è mica una stringa o una data, né un numero,
come puoi salvarla su db come se lo fosse? Almeno questo è
quello che penso io.
 
 

<L'immagine non � mica una stringa o una data, n� un numero,
<come puoi salvarla su db come se lo fosse? Almeno questo �
<quello che penso io.
 
� un array di byte (byte[] ),lo puoi considerare e salvare in tal modo.
 
 

Il 11/05/2013 15:46, kojak ha scritto:
 
l'approccio da te descritto � quello che utilizzano il 90% delle 
aziende, per farti capire FB utilizza lo stesso approccio (molto pi� 
sofisticato ma in line di principio lo stesso).
 
Questo consente di avere alte prestazioni su db, e risparmio di spazio 
(condivisione delle immagini con pi� persone), ridondanza, e possibilit� 
di avere un db snello e suddividere il carico dei file su pi� server, 
oppure gestire i file con servizi esterni (tipo dropbox, S3 di amazon, e 
altri)
 
facilt� nell'ispezionare il contenuto qualora necessario, ecc..
 
Ciao