Qual è un metodo migliore per archiviare le immagini - cartella o SQL Server come binari?

Question

Ho in programma lo sviluppo di una foto gallery richiesta di un cliente. Sto sviluppando l'app in asp.net 3.5 e vorrei svilupparla in modo da poter riutilizzare l'applicazione su più piattaforme utilizzando vari front-end. In sostanza, mi chiedo quali sono i dis-vantaggi e vantaggi di memorizzare le immagini nel database come file binari in contrasto con l'archiviazione semplicemente i file nella cartella di un'applicazione.

Qualsiasi consiglio sarebbe molto apprezzato!

Grazie, Tristan

Answer 1

Lo svantaggio di memorizzare in formato binario è che si soffia la dimensione del database di dimensioni incredibili. Se si dovesse utilizzare una versione Express di SQL Server, che è limitata a 4 GB per database, la galleria fotografica "terminerà" abbastanza presto.

Il vantaggio è che si può facilmente manipolare le limitazioni di accesso per file e per utente. Basta guardare i diritti degli utenti e decidere se restituire o meno l'immagine.

Answer 2

SQL Server 2008 supporta FILESTREAM stoccaggio.

I file sono memorizzati su un NTFS volume di come i file semplici, ma sono soggetti a controllo delle transazioni e si può accedere tramite i nomi di file speciali passati alla Win32 API funzioni (e, naturalmente, qualsiasi API costruito su di esso) con ulteriori SQL Server controlli di sicurezza (come le opzioni GRANT ecc.).

Answer 3

File Storage System offrirà prestazioni molto migliori nel salvare e servire le immagini, ed è supportato in tutte le piattaforme. Se riesci a vivere senza le doti di sicurezza e transazionali ottenute dall'archiviazione db, allora andrei con il file system.

Answer 4

Questo dibattito è in corso da in quasi tutte le comunità di SQL Server per le età. ci sono buoni argomenti per entrambe le parti e non c'è sicuramente una sola risposta adatta a tutte le dimensioni. Dipende molto dalla tua situazione individuale e da molti fattori, come il numero di utenti, avg. dimensione del file, frequenza di aggiornamento, rapporto lettura/scrittura, sottosistema disco yadayadayada ...

Ma come si cita SQLExpress probabilmente il fattore più importante è il limite massimo di dimensioni del database e questo è un ottimo motivo per andare per il filesystem approccio. Comunque, questo documento di ricerca potrebbe essere ancora interessante per te: To BLOB or Not To BLOB: Large Object Storage in a Database or a Filesystem?

Questo documento era sul sito di Microsoft Research qui: http://research.microsoft.com/apps/pubs/default.aspx?id=64525, ma quel link non funziona per me. SQL Server ha fatto molta strada da allora. Quassnoi ha già citato FILSTREAM, per esempio.

Answer 5

Avevamo una grande applicazione LOB che forniva ai cassieri bancari informazioni di identificazione sul membro in piedi di fronte a loro. I nostri dati testuali sono stati archiviati in SQL Server. I dati dell'immagine sono stati archiviati in file. Il campo del database aveva semplicemente un nome file. Questo approccio funziona bene se sei dietro il firewall. Leggere e scrivere file è facile. Il problema è la gestione dei file. È necessario proteggere il file system in modo che le persone a caso non possano visualizzare la directory. Inoltre, i backup sono più complicati con file di immagini sfusi. Devi fare il backup del database e dei file immagine. I campi possono fare riferimento a percorsi che non esistono più. Ad esempio, alcuni tizio IT decide di spostare la cartella dell'immagine e ora tutti i riferimenti nel db sono interrotti. Se l'applicazione deve passare le informazioni attraverso il firewall, suggerirei di archiviare le immagini in SQL Server utilizzando la memoria FileStream menzionata.

La memorizzazione delle immagini nel database ci avrebbe risparmiato un po 'di dolore. Avremmo solo dovuto eseguire il backup del database, sarebbe stato più sicuro, i riferimenti non si sarebbero mai interrotti e non avremmo dovuto saltare i telai per ottenere file dalla rete al di fuori del firewall.