Quale è meglio: Archiviazione / recupero di immagini su / da server SQL o in una directory sul server

Preferisco inserire i binari nel database, ma principalmente perché

• So dove si trova e non ho bisogno di un addetto ai sistemi per impostare una condivisione di rete o un server web.
• Posso controllare chi può recuperare i dati tramite la mia applicazione, piuttosto che fare affidamento sulle autorizzazioni sul file system. Posso farlo molto facilmente a livello molto dettagliato.
• Ricevo un'integrità transazionale molto più semplice quando inserisco file rispetto a un file system.

Il miglior argomento contro l'archiviazione del database è intorno alle dimensioni - il database potrebbe diventare ingestibile. Molto più difficile da fare backup e amp; Manutenzione; il database è un file enorme , mentre se i file sono esterni, puoi averne un po 'qui e altri là.

Se stai usando Microsoft, forse il miglior compromesso è il tipo FileStream . Memorizza il percorso file nel database e i file in una cartella, ma la cartella è essenzialmente controllata da SQL. Si "inseriscono" i file nel database e vengono salvati nella cartella, e quando si "seleziona" dal database il server li recupererà dalla cartella e servirà attraverso il database. In questo modo ottieni il meglio da entrambi i mondi: transazioni e controllo, oltre all'efficienza delle dimensioni di mantenere il database piccolo.

È stato discusso qualcosa di molto simile a cui avevo risposto, che era inevitabilmente il metodo 1. Qui puoi vedere una discussione simile: Come aggiungere il supporto dell'immagine al client- applicazione per database server?

Se chiedi perché, la ragione fondamentale per cui preferisco il metodo web è che quando un'applicazione richiede l'immagine reale, ha un singolo punto di errore.

1. Diventa un must che finalmente il database deve recuperare. Il recupero da DB è più costoso (per altre transazioni) rispetto al recupero dal file system.

2. Di solito c'è sempre un livello server (ASP o C #) che effettivamente effettua una chiamata al DB (i client o il browser web non chiamano direttamente DB). quindi, il percorso ha un ulteriore punto di collo di bottiglia. Se c'è un URL statico (possibilmente con auth) - il browser può prelevare direttamente piuttosto che passare attraverso il server delle applicazioni.

3. Soprattutto, immagino che, quando si consegnano le immagini a molti browser (da un server web), il ridimensionamento è molto più facile in questo modo piuttosto che in un altro modo.

4. Ultimo ma la maggior parte, in molti casi, le immagini recuperate utilizzando gli URL statici, possono essere facilmente memorizzate nella cache dal browser stesso per risparmiare più risorse.

Sono d'accordo con la risposta di cui sopra e i criteri in " A BLOB o Not To BLOB "ma la maggior parte delle risposte si concentra sulla velocità di recupero e sulla dimensione del database come criterio.

Il mio punto è che ci sono criteri aggiuntivi - è la frequenza con cui le immagini cambieranno, e quando e come vogliamo fornire queste immagini è ugualmente un criterio critico.

Se il contenuto dell'immagine continua a cambiare e la logica dell'applicazione deve elaborarli prima di consegnarla, ha più senso consegnare tramite app server (vale a dire che puoi conservare in DB). Dove, come se le immagini per natura stessa fossero abbastanza statiche - non cambiano spesso e devono essere consegnate così tante volte, (imposta una volta letto / consegna molte volte), allora il web è sempre un metodo preferito. questo vale indipendentemente dalle prestazioni del DB.

Sebbene questo sia stato chiesto su StackOverflow, penso che ci sia un'assunzione automatica tra i programmatori su questo argomento che potrebbe non essere sempre valida, quindi sto rispondendo qui. Ci sono situazioni in cui il posizionamento nel database potrebbe essere migliore.

link Esiste un link qui che mostra che le dimensioni del file possono essere importanti e posizionare piccole immagini in un database può essere migliore per le prestazioni. Attualmente, 250K a 1 M sembra essere l'area grigia. Questo è specifico per SQL Server 2008. Suppongo che più database relazionali rompano un po 'il loro stampo e inizino a migliorare la loro capacità di gestire grandi quantità di dati.

Potrebbero anche essere migliori per l'indicizzazione e la ricerca di contenuti di blob. Non vedo l'ora che arrivi il giorno in cui posso interrogare tutte le immagini per chi Dove Photos.File.FaceCount > 1 per ottenere foto di gruppo senza che qualcuno debba creare manualmente i metadati.