HELP: Immagini in DB MySQL
Giuseppe Lupo
Problema:
realizzare un database in MySQL nel quale le tabelle contengono campi nei
quali si ha la necessità di inserire delle immagini.
vorrei sapere come fare per inserire in un campo un'immagine.
Grazie
Giuseppe Lupo
Palermo
P.S. scusate il cross-post
Davide Bianchi
news:VoHk8.25121$1S3.8...@twister1.libero.it...
> realizzare un database in MySQL nel quale le tabelle contengono
> campi nei quali si ha la necessità di inserire delle immagini.
Non mettere l'immagine nel database, lascia il file su disco e
nel database mettici il path/nome del file.
Davide
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
punkarruso
se in php:
sql="insert into table (campoblob) values (".addslashes($immagine).")";
non dare retta a davide...
la gestione su db, prestazioni a parte, è decisamente più facile e sicura.
ciao
punkarruso
news:9f4ced52a8e94522195...@mygate.mailgate.org:
> Non mettere l'immagine nel database, lascia il file su disco e
> nel database mettici il path/nome del file.
la domanda che ha fatto mi sembra chiara...
non era "db||fs?" ma "db:come?"
ciao
gprix
Effettivamente ho ancora dei dubbi: mettere le immagini nel db non ne fa
aumentare le dimensioni ben oltre l'effettivo ammontare dei file? Non si
finisce per
appesantire troppo il db?
Faser
>non dare retta a davide...
>la gestione su db, prestazioni a parte, è decisamente più facile e sicura.
Se parliamo di web, mettere le immagini nel db è invece decisamente
negativo. Alcune veloci considerazioni, visto che sono di fretta:
1) Il database diventa intrasportabile con connessioni lente.
2) Grossi problemi per far fare al web server il suo lavoro di caching.
Questo probabilmente è il punto più importante.
3) Impossibile lavorare direttamente sulle immagini o fare velocemente
semplici thumbnails delle cartelle.
Sono pochissime le reali esigenze per mettere le immagini nel db, se
proprio devi mettile su una tabella a parte.
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
--------------------
punkarruso
news:4a293a6ceb26d337076...@mygate.mailgate.org:
> Effettivamente ho ancora dei dubbi: mettere le immagini nel db non ne fa
> aumentare le dimensioni ben oltre l'effettivo ammontare dei file? Non si
> finisce per
> appesantire troppo il db?
per un blob normale, oltre alla dimensione dell'immagine in se richiede 2
bytes.
come gestione il db si appesantisce proprio come si appesantirebbe il
filesystem...
ciao
punkarruso
news:mi1f9uo1evor3vgr4...@4ax.com:
> 1) Il database diventa intrasportabile con connessioni lente.
su web, considera anche chi non ha un account remoto ma ha in rete il
proprio server e lo può gestire in locale...
poi puoi trasportare tutto il db in un solo botto mentre per il fs devi
ricorrere a programmi di tar... con i problemi che conseguono.
e non parliamo del problema win-linux. per fare un porting rischi di
portarti dietro .jpg .JPG ecc...
> 2) Grossi problemi per far fare al web server il suo lavoro di caching.
> Questo probabilmente è il punto più importante.
vabin
> 3) Impossibile lavorare direttamente sulle immagini o fare velocemente
> semplici thumbnails delle cartelle.
...e perché no?? evidentemente non hai mai provato!!
posso pescare da db le immagini, lavorarle e riversarle senza passare su
fs...
esattamente come faresti con fread e fwrite.
su fs ammetto che è molto + veloce (io stesso ho fatti dei bench che poi ho
riportato su it.comp.www.php), circa il 170% più veloce.
se però si parla di gestione di quantità industriali di thumbs, il db è
quello che ci vuole...
conta che su fs con centinaia di migliaia di immagini, il browsing diventa
pesantissimo (dipende anche dal fs), mentre il db è ottimo perché
indicizzabile e può estrarre un'immagine su un milione in molto meno
tempo...
> Sono pochissime le reali esigenze per mettere le immagini nel db, se
> proprio devi mettile su una tabella a parte.
un campo blob viene comunque salvato in settori distinti dalla struttura
fisica della tabella, e finché non viene selezionato direttamente non
impatta con le scansioni...
poi non rischi avere incongruenze tra dato su tabella e dato su
filesystem... e non è un rischio da poco!!!
ciao!
Faser
>Faser <inv...@faser.net> wrote in
>news:mi1f9uo1evor3vgr4...@4ax.com:
>
>> 1) Il database diventa intrasportabile con connessioni lente.
>
>su web, considera anche chi non ha un account remoto ma ha in rete il
>proprio server e lo può gestire in locale...
In questo caso, ok.
>...e perché no?? evidentemente non hai mai provato!!
>posso pescare da db le immagini, lavorarle e riversarle senza passare su
>fs...
>esattamente come faresti con fread e fwrite.
Boh io so solo che con PSP o altri programmi di grafica il lavoro mi
verrebbe impossibile. Se poi ti fai un programma ad hoc è un altro
discorso.
>poi non rischi avere incongruenze tra dato su tabella e dato su
>filesystem... e non è un rischio da poco!!!
Questo hai ragione ed è infatti forse il motivo principale per archiviare
in un db.
gprix
> Boh io so solo che con PSP o altri programmi di grafica il lavoro mi
> verrebbe impossibile. Se poi ti fai un programma ad hoc è un altro
> discorso.
>
> >poi non rischi avere incongruenze tra dato su tabella e dato su
> >filesystem... e non è un rischio da poco!!!
>
> Questo hai ragione ed è infatti forse il motivo principale per archiviare
> in un db.
>
Scusate, potreste spegare cosa intendete con questa incongruenza?
Ciao, grazie.
>Ciao.
> Faser
punkarruso
news:369d9082223cad4ab4d...@mygate.mailgate.org:
> Scusate, potreste spegare cosa intendete con questa incongruenza?
> Ciao, grazie.
che il tuo script di gestione db->fs deve essere DAVVERO collaudato
altrimenti rischi di trovarti record "defunti" nel db o files "cadaveri"
che non vengono + ripescati da nessun record...
ovvero la struttura dei files tracciata dal db non corrisponde al 100% con
quella reale...
(per errori di vario genere).
ciao!
Leonardo Serni
>> Scusate, potreste spegare cosa intendete con questa incongruenza?
>> Ciao, grazie.
>che il tuo script di gestione db->fs deve essere DAVVERO collaudato
>altrimenti rischi di trovarti record "defunti" nel db o files "cadaveri"
>che non vengono + ripescati da nessun record...
Per una gestione ordinaria, le due funzioni InsertFile e DeleteFile
basta che eseguano anche l'inserimento/cancellazione del DB... e la
gestione degli errori basta farla li'.
Per avere cintura e bretelle uno script che traversa il fs e a ogni
file controlla il DB elimina i record defunti; lo script simmetrico
che traversa il database elimina i files orfani.
Leonardo
--
".signature": bad command or file name
punkarruso
news:75v5ausjfqgb9eu9j...@L.Serni:
> Per avere cintura e bretelle uno script che traversa il fs e a ogni
> file controlla il DB elimina i record defunti; lo script simmetrico
> che traversa il database elimina i files orfani.
trassare non risolve il problema...
se hai incongruenze, il problema non è toglierle. è che si creino.
se hai un file in +, come fai a sapere se è il file che non si è cancellato
o il record che non si è inserito?
se hai un sistema "alla buona" va bene. ma se per esempio è l'anagrafica
dei dipendenti di un'azienda, è diverso!!
ciao
Leonardo Serni
>> Per avere cintura e bretelle uno script che traversa il fs e a ogni
>> file controlla il DB elimina i record defunti; lo script simmetrico
>> che traversa il database elimina i files orfani.
>trassare non risolve il problema...
>se hai incongruenze, il problema non è toglierle. è che si creino.
Be', nel caso per esempio di INSERT:
if (insertBlankRecord(...)!=EXIT_SUCCESS)
return EXIT_FAILURE;
if (updateDBRecord(...)!=EXIT_SUCCESS)
{
// DB in stato consistente: il record non punta
// ancora a nulla
jprintf(J_WARNING, "Cannot update record.");
return EXIT_FAILURE;
}
// Qui so che posso almeno almeno blankare il record.
if (createFile(...)!=EXIT_SUCCESS)
{
if (deleteDBRecord(...)!=EXIT_SUCCESS)
{
if (blankDBRecord(...)!=EXIT_SUCCESS)
{
// Boia, prima potevo... e ora no?!?
jprintf(J_WARNING, "File ... could not be
created; record ... inserted could not be deleted or blanked!");
return EXIT_FAILURE;
}
jprintf(J_WARNING, "File ... could not be created;
record ... inserted could not be deleted and has been blanked out.");
}
jprintf(J_WARNING, "File ... could not be created; record
... has been deleted.");
return EXIT_FAILURE;
}
Questo e' un problema che si verifica in millanta casi, perche' un DB non
e' fatto di sole operazioni atomiche. Il sistema fa del suo meglio, e, se
non ci riesce, segnala errore.
>se hai un file in +, come fai a sapere se è il file che non si è cancellato
>o il record che non si è inserito?
In entrambi i casi ho una segnalazione di errore preesistente. Per es. se
non c'e' spazio su disco o sul DB, mi si crea una situazione losca, ed io
devo _comunque_ intervenire (non foss'altro che per verificare che non ci
sia stato un guaio di qualche tipo).