Newsgroup: it.comp.www.php
Titolo: Immagini nel database [blob]

come avevo scritto una settimana fa, stavo stendendo un piccolo 
white-paper sull'argomento:
http://punkarruso.altervista.org/techdocs/ImageIntoDB.pdf
fa cagare, lo so, ma visto che non ho trovato di meglio in rete ho 
provato a farlo io... non scrivo mai docs per altri!
se avete correzioni da fare, massacratemi pure in posta privata.
ciao
-- 
punkarruso

 posted this:

good!

 ha detto:
Da non troppo esperto di php/mysql lo trovo ben fatto ed utile, grazie

 wrote:

a me dà "Errore 403, Non puoi accedere alla pagina o directory
desiderata etc etc"
???

 provato a farlo io... non scrivo mai docs per altri!
Hai fatto un ottimo lavoro (da linkare alle FAQ S_U_B_I_T_O!!!) ma...
<Trolling On>
Non riuscirai mai a convincermi che mettere le immagini di un CMS 
web-based nei BLOB sia una buona idea, spiacente!
<Trolling OFF>
Più seriamente: ammetto di aver letto in maniera affrettata il documento 
ma mi permetto di mettere un altro sassolino sulla bilancia pro-filesystem:
- La presenza di tipi di dato LONG, BLOB, BYTEA ecc. ecc. in un DB in 
genere inficia l'utilità delle funzioni di import-export o di 
backup-restore dei dati basate sulla generazione di script SQL. Nella 
mia esperienza queste utility sono invece indispensabili per risolvere 
problemi di porting e realizzazione di batch di scambio dati fra sistemi 
eterogenei. Dato che molti degli aspetti 'negativi' che attribuisci alla 
soluzione basata su filesystem sono collegati a situazioni del genere, 
mi pareva opportuno sottolinearlo ;-)
un altra considerazione: è vero che la ricerca di un file tramite 
accesso all'i-node è meno efficiente di un DB seek e che il numero degli 
i-node è limitato, eccetera. Tuttavia questi aspetti possono essere 
limitati creando nel filesystem una struttura ad albero il più possibile 
bilanciato, cosa non difficilissima se ci si basa o su informazioni 
sulla natura delle immagini che si sta memorizzando (es. dividere le 
immagini di un album fotografico per cronologia/soggetto) o su semplici 
accorgimenti astratti (es. divisioni basate sul primo carattere del 
filename e così via).
just my 0.02 € :-)
-- 
Fabrizio "Hermooz" Ermini

 filename e così via).
mi sembrano OTTIME considerazioni!
anche secondo me sono validissime. se non le ho inserite è perché:
la prima non mi è venuta in mente
la seconda non sapevo come metterla giù, ma nei riferimenti in fondo al 
doc è presente questo fatto.
se ho tempo (questo periodo davvero poco) aggiungo queste considerazioni 
(par condicio :-) ) e assolutamente devo aggiornare la faq che com'è 
adesso funziona solo con mysql e non su tutti come sembrerebbe...
pensare che ho iniziato a stendere il documento credendo di sapere dove 
stavo andando, invece ho già scoperto un sacco di cose nuove!!
grazie
-- 
punkarruso

 ciao
grandioso, complimenti...
Riguardo ai test come si spiega che un PII 200 su linux vada più forte 
di un PIII 500 su winzozz 2000 ?? :D
Credi sia dovuto alle differenze di prestazioni FAT32-ext3 oppure è 
semplicemente uno dei misteri della fede MS ?? :D
ciao
Alesi_27


è stata la cosa che mi ha divertito di più nei test...
oltre alle due che hai detto, non ho specificato che su linux gira 
apache2 mentre su win32 l'1.3, poi a detta degli sviluppatori, con mysql 
4 han fatto grandi sforzi per migliorare le prestazioni coi blobs.
poi, il pIII è la mia macchina (di solito usavo linux ma sono costretto 
per motivi mssql...) e ho di tutto di più installato, comprese librerie 
sminchiate...
comunque, una bella prova del pinguino!
-- 
punkarruso

 grazie
Scherzi, grazie a te. Ce ne fossero stati in giro di documenti così 
qualche anno fa... ;-)
Ciao!
-- 
Fabrizio "Hermooz" Ermini

 fottuta colonna LONG... :-)
[ot]
ROTFL, si!
se hai accesso (cut&paste):
http://metalink.oracle.com/metalink/plsql/ml2_documents.showNOT
?
p_id=132904.1&p_showHeader=1&p_showHelp=1
-- 
punkarruso

 se hai accesso (cut&paste):
eh eh eh! Ce l'hai nei bookmark eh?
Proprio per evitare di infognarmi in queste cose, dato che capita spesso 
di dover fare delle prove un po' su un DB un po' su un altro, ho 
l'abitudine di usare la funzione di export in SQL script di PL/SQL 
developer, che funziona molto bene. Così, magari mettendo a posto a mano 
qualche nome di tablespace o altre inezie, si possono facilmente 
spostare oggetti (spesso anche da un DBMS all'altro, soprattutto 
Oracle<->PostgreSQL dove mi sento molto di più a casa :-)).
Quando in quel caso ho visto che c'era quella colonna LONG e che non mi 
funzionava l'export è stato come se mi avessero sfilato di botto la 
sedia da sotto al culo :-)


 
http://punkarruso.altervista.org/techdocs/ImageIntoDB.pdf
 fa cagare, lo
Se posso permettermi qualche nota sulla parte "estetica" ti consiglierei
di
- separare i test, uno per pagina. In pratica mettere un pagebreak alla
fine di ogni capitolo dei test.
- Mettere un grafico riassuntivo delle prestazioni
Grazie comunque per il documento, e` stato molto interessante, non
sapevo dell'esistenza di due tipi di blob in postgres.
Bye.

 white-paper sull'argomento<snip>
Magari potrei essere smentito nell'attualita', il supporto di php a
sql server (intendo le chiamate 'native', mssql_* )ancora non ha la
gestione dei blob. Qualcuno ha novita' o altro a riguardo?
TIA
-- 
Real email address hasn't .nntp

 gestione dei blob. Qualcuno ha novita' o altro a riguardo?
si, secondo quanto c'è scritto nel manuale, la gestione avviene tramite 
codifica esadecimale dell'informazione
quindi per l'inserimento *dovrebbe* essere:
$sql="insert into tabella (campo_image)
    values (0x".bin2hex($contents).");
uso il condizionale perché sebbene lavori su mssql, non usiamo immagini 
per il progetto attuale e a dire il vero ci tengo pure poco...
anzi, avessi potuto scegliere io il dbms... :-(((((
-- 
punkarruso