Salvere immagini

lunedì 24 marzo 2008 - 20.15

bluland Profilo | Guru

Salve,

volevo un consiglio,

attraverso una web page devo salvare delle immagini su SQL server 2000
ora mi chiedevo cosa conviene di piu salvarne solo i link e mettere le vere immagini in una cartella o inserirle nel db?

Aspetto pareri ed opinioni.


CIao
--------------------
Vincenzo PESANTE
System Engineer

alx_81 Profilo | Guru

>Salve,
Ciao!

>
>volevo un consiglio,
ti rimando a questo post:
http://www.dotnethell.it/forum/messages.aspx?ThreadID=18043
Alx81 =)

http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org

bluland Profilo | Guru

Beh per quanto riguarda il mio caso, credo che le immagini non saranno molto pesanti,
però c'è ne sarà un grande numero che sarà sempre crescente, infatti insieme ad ogni record salvato in apposite tabelle verrà salvata anche l'immagine.

In questo caso che mi consigli?


Ciao
--------------------
Vincenzo PESANTE
System Engineer

alx_81 Profilo | Guru

>Beh per quanto riguarda il mio caso, credo che le immagini non
>saranno molto pesanti,
>però c'è ne sarà un grande numero che sarà sempre crescente,
>infatti insieme ad ogni record salvato in apposite tabelle verrà
>salvata anche l'immagine.
>
>In questo caso che mi consigli?
Credo che se il numero cresce veramente usare il filesystem sia la cosa migliore. Anche se perdi la possibilità di eseguire il backup delle informazioni (immagini per te) insieme a quello del database, o meglio, sei costretto ad escogitare un piano di backup aggiuntivo.
Tendo ad utilizzare il db come repository di immagini solo quando si tratta di poche righe e di immagini di dimensioni ridotte.
Alx81 =)

http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org

bluland Profilo | Guru

>>Beh per quanto riguarda il mio caso, credo che le immagini non
>>saranno molto pesanti,
>>però c'è ne sarà un grande numero che sarà sempre crescente,
>>infatti insieme ad ogni record salvato in apposite tabelle verrà
>>salvata anche l'immagine.
>>
>>In questo caso che mi consigli?
>Credo che se il numero cresce veramente usare il filesystem sia
>la cosa migliore. Anche se perdi la possibilità di eseguire il
>backup delle informazioni (immagini per te) insieme a quello
>del database, o meglio, sei costretto ad escogitare un piano
>di backup aggiuntivo.
>Tendo ad utilizzare il db come repository di immagini solo quando
>si tratta di poche righe e di immagini di dimensioni ridotte.

Perche in caso inverso quali sarebbero le contro indicazioni?

sai sto facendo una sorta di analisi per fare anche un scelta architetturale.

CIao e grazie
>Alx81 =)
>
>http://blogs.dotnethell.it/suxstellino
>http://mvp.support.microsoft.com/profile/Alessandro.Alpi
>http://italy.mvps.org

--------------------
Vincenzo PESANTE
System Engineer

alx_81 Profilo | Guru

>Perche in caso inverso quali sarebbero le contro indicazioni?
Allora proverò a darti una risposta completa. Sto parlando di SQL Server e, credo, di moltri altri DBMS.
Salvare le immagini su database non è giusto o sbagliato, è una scelta da ponderare. Innanzitutto bisogna capire come SQL Server si comporti con i campi definiti BLOB (Binary Large Object, text,ntext,image). In un campo di questo tipo non viene salvato il contenuto bensì un puntatore che occupa qualche byte e che occupa alla zsona effettiva su cui si trova il BLOB. Di conseguenza potrebbe essere meno performante la scelta di un varchar per un path al posto di un campo binary.
Salvando i dati su database hai alcuni vantaggi:
- Le immagini non apensantiscono il db per quanto riguarda filtri e ricerche
- Puoi sfruttare comunque la cache del browser
- Puoi sfruttare le transazioni
- Puoi avere le informazioni centralizzate e quindi backup e restore ottimi per la gestione di "tutto"

Salvando i dati su db però potresti avere anche alcuni problemi. Ad esempio, ed è il motivo per cui ti dicevo che a volte mi capita di salvare su filesystem, perdi il nome del file e alcune altre sue proprietà. Ed in alcuni casi questo non è consentito. Poi, non dimentichiamo che se devi elaborare le immagini è molto più complessa la gestione a db. Devi considerare anche questo.

Uno dei più grandi svantaggi dell'utilizzo del filesystem invece è quello di distribuire il contenuto (un po' su db un po' su filesystem). Di conseguenza nasce una complicata gestione dei dati con la possibilità di lasciare anche dati sporchi sul db. Infine, le permission e la security in generale, laddove si esca dal contesto del database.

Con SQL Server 2008 è stato introdotta l'opzione FILESTREAM che ti consente di gestire il filesystem "sotto transazione":

"Il nuovo tipo di dati FILESTREAM di SQL Server 2008 consente di memorizzare dati binari di grandi dimensioni, come documenti e immagini, direttamente in un file system NTFS; il documento o l'immagine resta una parte integrante del database e mantiene l'uniformità transazionale. FILESTREAM consente l'archiviazione di dati binari di grandi dimensioni, gestiti in passato dal database, da memorizzare all'esterno del database come file singoli a cui è possibile accedere utilizzando un'API che utilizza il flusso di dati NTFS. Utilizzando API che sfruttino il flusso di dati NTFS, si ottengono prestazioni efficaci di operazioni su file comuni e al tempo stesso sono a disposizione tutti i servizi database completi, compresi la protezione e il backup."


Alx81 =)

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org

bluland Profilo | Guru

Capito,

poiche sara' un'applicazione che dovra' tracciare dati giornalieri capisci che la mole di immagini potra' essere anche abbastanza grossa nel tempo, per cui il db ne potrebbe anche risentire,
a questo punto sarei tentato per la strada del salvataggio solo dei link,

tu che scelta effettueresti dato lo scenario


Ciao
--------------------
Vincenzo PESANTE
System Engineer

alx_81 Profilo | Guru

>poiche sara' un'applicazione che dovra' tracciare dati giornalieri
>capisci che la mole di immagini potra' essere anche abbastanza
>grossa nel tempo, per cui il db ne potrebbe anche risentire,
>a questo punto sarei tentato per la strada del salvataggio solo
>dei link, tu che scelta effettueresti dato lo scenario
Come ti dicevo, se ti fa comodo avere i dati centralizzati e se non devi manipolarle, db..
Pensa comunque anche ai tempi di backup.. E quindi al fatto che più le immagini sono leggere meglio è.
Alx81 =)

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org

bluland Profilo | Guru

Beh devo pensarci,

infatti penso anche al fatto di fare un restore tra qualche tempo, sai che db che mi troverei!!
Calcolando anche il fatto che l'attuale db dove implementare questa funzionalità sfiora i 5 gb.


Grazie cmq ciao
--------------------
Vincenzo PESANTE
System Engineer

alx_81 Profilo | Guru

>Beh devo pensarci,
>
>infatti penso anche al fatto di fare un restore tra qualche tempo,
>sai che db che mi troverei!!
>Calcolando anche il fatto che l'attuale db dove implementare
>questa funzionalità sfiora i 5 gb.
Mi è venuta in mente un'altra cosa..
Se le immagini che devi inserire sono pesanti, considera anche che i tempi di ogni transazione a db potrebbero dilatarsi.
Fai le più accurate considerazioni.
Chiudiamo il post per favore

>
>Grazie cmq ciao
Ciao!

Alx81 =)

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org

bluland Profilo | Guru

Si infatti

grazie Ciao
--------------------
Vincenzo PESANTE
System Engineer
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2025
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5