Newsgroup: it.comp.www.php
Titolo: Archiviare immagini

Salve,
come faccio ad archiviare le immagini dei prodotti che inserisco in una
tabella mysql?
scenario:
tabella prodotti;
di ogni prodotto esiste un'immagine;
uso php4 per visualizzare questi prodotti su web;
ho necessità di visualizzare accanto ad ogni prodotto anche l'immagine
relativa;
quindi nella tabella prodotti dovrei creare un campo che contenga
un'immagine o il path relativo all'immagine in modo da richiamarla da
script:
Inserire l'url dell'immagine in un campo varchar (50) e visualizzarla poi
con un :
echo $img_url;
lasciando quindi l'immagine stessa in una dir è semplice...
ma se volessi registrarla nella tabella? e quindi cancellarla completamente
dal disco? si può fare?
qualcuno ha qualche script in modo che io possa studiarlo  e capire il
procedimento?
E cmq, qual'è il metodo migliore? inserire l'url ad una immagine sul disco o
archiviarla direttamente nella tabella?
Grazie a tutti :)

 Grazie a tutti :)
IL modo migliore in assoluto è mettere le immagini in una dir e chiamarle
con numeri progressivi, questi numero verranno registati in qualche tabella
esempio:
ID, DESC
ID chiave e numero associato all'immagine
DESC descrizione se necessaria
Quando vorrai cancellarla il nome del file ce l'hai perchè hai l'ID e la
cancelli con unlink("nomefile")
Non chiamare mai le immagini con i nomi reali che hai anche sul tuo HD,
perchè potrebbe capitare che alcuni nomi validi per Windows o Linux, poi
siano un problema sotto PHP con l'HTML, inoltre poi dovresti conservare i
nomi e questo occupa spazio, mentre se conservi solo un numero è tutto più
snello e ci sono meno prob. di errori.
Un nome di file che procura problemi?
"ciccio&company.jpg"
Perfettamente valido su Windows e Linux, ma prova a mettere  nomi del genere
in script che devono gestire quello che hai detto te.
un altro?
"ciccio'o.jpg"
e ce ne sono una infinità
Per cui è meglio prendere il file e farlo scrivere con nomi simili a numeri
progressivi
1.jpg
2.jpg
3.jpg
così non ci sono prob.
e risparmi un sacco di spazio nelle tabelle.

 o archiviarla direttamente nella tabella?
dipende dalle esigenze e dalla tua capacità di scrivere codice robusto.
se l'immagine la tieni su FS, è la tua applicazione che deve gestire 
l'integrità referenziale "record <-> immagine"
se invece inserisci l'immagine nel db, sai che la delete (o update) ti ha 
sicuramente cancellato anche l'immagine.
poi dipende da cosa ci devi fare, ci sono un sacco di vantaggi/svantaggi.
(il vantaggio + immediato è che nessuno ti può sbirciare le immagini a meno 
che non gliele passi tu!, lo svantaggio è la performance: fino a qualche 
migliaio di record il fs è + veloce a gestire le immagini che non il db. se 
però il numero sale di molto il db ha la possibilità di indicizzare la 
ricerca!)
ciao
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.gnu.org/philosophy/motivation.it.html

Scusa ma non è sempe più snello usare le immagini in una directory?
Quando vado a prendere il file zuzzerellone.jpg, in una directory con 2000
file, non credo che il sistema operativo si spulci tutti i file prima di
trovare il mio....o mi sbaglio?
Non dovrebbe fare una ricerca partendo da metà, poi la metà della metà fino
a raggiungere il file?
--
Cordialmente.
Carmelo Carchedi
Il mio e-mail non ha numeri,
ricordati di toglierli per rispondere privatamente.
Juniorbit Sas
www.juniorbit.it

 fino a raggiungere il file?
dipende. hai mai provato a creare un milione di files sotto una dir sola?
a seconda del filesystem, la reazione è diversa. ma un punto di crollo 
delle prestazioni ce l'hanno tutti i FS (ext3, reiser e NTFS compresi).
un database ha invece la possibilità di creare indici molto performanti 
(anche clusterizzati) su un numero teoricamente illimitato di record e la 
ricerca hw è limitata al datafile e non a tutto il FS (risparmio degli 
spostamenti della testina non indifferente).
la ricerca del dato con immagine su fs si traduce in:
ricerca nel db (index) -> seek sul record -> estrazione dati -> ricerca su 
fs -> seek (probabilmente spalmato su n blocchi) -> output (molto rapido)
la ricerca su db invece:
ricerca nel db (index) -> seek sul record -> estrazione dati -> output (un 
po' + lento)
quindi, tutto dipende dalla quantità di dati in cui ricercare:
pochi dati -> molto meglio fs
tanti dati -> molto meglio db
(con tutte le sfumature del caso).
la prox settimana mi arriva in ufficio l'hd nuovo (comprato io, non 
l'azienda!) e magari farò delle prove in quest'ottica, su qualche milione 
di record.
un primo benchmark che avevo fatto (del tutto sbagliato) era del tipo:
"con circa 10000 immagini su db e altrettante su fs, carica 2 pagine php 
che prendono i dati dalle 2 fonti e calcola la differenza di tempo"
la velocità del FS era doppia, ma estraevo TUTTI i records...
adesso voglio provare (e crasharmi un FS ad hoc!) con (1 milione)+ di 
record e cercando l'immagini per 1 solo id in input per volta.
faccio poi sapere!
ciao
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.efluxa.it/netiquette/dis.html