Archiviazione di immagini in SQL Server?


191

Ho creato un piccolo sito dimostrativo e su di esso sto memorizzando immagini all'interno di una colonna di immagini sul server sql. Alcune domande che ho sono ...

  • È una cattiva idea?

  • Interesserà le prestazioni sul mio sito quando cresce?

L'alternativa sarebbe quella di memorizzare l'immagine su disco e memorizzare solo il riferimento all'immagine nel database. Questo deve essere un dilemma comune che molte persone hanno avuto. Accolgo con favore alcuni consigli e sarei davvero felice di fare un piccolo errore se potessi.


5
C'è qualche nuova aggiunta per questo problema nel 2017? È valido ancora oggi?
Haikal Nashuha,

Risposte:


273

C'è un ottimo documento di Microsoft Research chiamato To Blob o Not To Blob .

La loro conclusione dopo un gran numero di test e analisi delle prestazioni è questa:

  • se le tue immagini o documenti hanno dimensioni inferiori a 256 KB, archiviarle in una colonna VARBINARY del database è più efficiente

  • se le immagini o i documenti hanno dimensioni superiori a 1 MB, la loro memorizzazione nel filesystem è più efficiente (e con l'attributo FILESTREAM di SQL Server 2008, sono ancora sotto controllo transazionale e parte del database)

  • tra quei due, è un po 'complicato a seconda del tuo uso

Se decidi di inserire le tue foto in una tabella di SQL Server, ti consiglio vivamente di utilizzare una tabella separata per la memorizzazione di quelle immagini - non conservare le foto dei dipendenti nella tabella dei dipendenti - conservale in una tabella separata. In questo modo, la tabella Employee può rimanere snella, cattiva e molto efficiente, supponendo che non sia sempre necessario selezionare anche la foto del dipendente, come parte delle tue query.

Per i filegroup, controlla File e Filegroup Architecture per un'introduzione . Fondamentalmente, dovresti creare il tuo database con un filegroup separato per strutture di dati di grandi dimensioni fin dall'inizio, o aggiungere un filegroup aggiuntivo in seguito. Chiamiamolo "LARGE_DATA".

Ora, ogni volta che hai una nuova tabella da creare che deve memorizzare le colonne VARCHAR (MAX) o VARBINARY (MAX), puoi specificare questo gruppo di file per i dati di grandi dimensioni:

 CREATE TABLE dbo.YourTable
     (....... define the fields here ......)
     ON Data                   -- the basic "Data" filegroup for the regular data
     TEXTIMAGE_ON LARGE_DATA   -- the filegroup for large chunks of data

Dai un'occhiata all'introduzione di MSDN sui filegroup e gioca con esso!


È una cosa positiva o negativa ... • se le immagini o i documenti hanno una dimensione superiore a 1 MB, archiviarli nel filesystem è più efficiente (e con l'attributo FILESTREAM di SQL Server 2008, sono ancora sotto controllo transazionale e parte del database)
htm11h,

Bella risposta. Se avete voglia di spiegare in dettaglio il motivo per cui si consiglia di utilizzare una tabella dedicata per i dati delle immagini, ho creato una domanda separata per che in dba.SE .
Heinzi,

15

Mi sono imbattuto in questo dilemma una volta e ho fatto parecchie ricerche su Google per ottenere opinioni. Quello che ho scoperto è che in effetti molti vedono salvare le immagini su disco meglio per immagini più grandi, mentre mySQL consente un accesso più facile, specialmente da linguaggi come PHP.

Ho trovato una domanda simile

MySQL BLOB vs File per la memorizzazione di immagini PNG di piccole dimensioni?

Il mio verdetto finale è stato che per cose come un'immagine del profilo, solo una piccola immagine quadrata che deve essere lì per utente, mySQL sarebbe meglio che archiviare un mucchio di pollici nel disco fisso, mentre per album fotografici e cose del genere, cartelle I file / image sono migliori.

Spero che sia d'aiuto


14

Preferirei archiviare l'immagine in una directory, quindi memorizzare un riferimento al file di immagine nel database.

Tuttavia, se si memorizza l'immagine nel database, è necessario partizionare il database in modo che la colonna dell'immagine risieda in un file separato.

Puoi leggere ulteriori informazioni sull'utilizzo dei filegroup qui http://msdn.microsoft.com/en-us/library/ms179316.aspx .


11

Perché può essere utile archiviare immagini nel database e non in un catalogo sul server Web.

Hai creato un'applicazione con molte immagini archiviate in una cartella sul server che il client utilizza da anni.

Ora vengono da te. Il loro server è stato distrutto e devono ripristinarlo su un nuovo server. Non hanno più accesso al vecchio server. L'unico backup che hanno è il backup del database.

Naturalmente hai l'origine e puoi semplicemente distribuirlo sul nuovo server, installare SqlServer e ripristinare il database. Ma ora tutte le immagini sono sparite.

Se hai salvato le immagini in SqlServer tutto funzionerà come prima.

Solo i miei 2 centesimi.


3
Buon punto. I backup delle immagini sono importanti tanto quanto i backup del database ... a volte anche di più.
Chris Catignani,

Anche le immagini sul file system richiedono autorizzazioni di rete.
Chris Catignani,

2
Le autorizzazioni di rete sono un buon punto. Ma non vedo un caso in cui avresti solo un backup del DB. Avresti sicuramente un backup dell'applicazione e dei file. Potresti anche perdere facilmente il DB ma avere i file.
Norbert Norbertson,



7

Mentre i problemi di prestazioni sono validi, i motivi reali nella pratica che è necessario evitare di archiviare immagini in un database sono per motivi di gestione del database. Il database crescerà molto rapidamente e i database costano molto più della semplice archiviazione di file. I backup e i ripristini del database sono molto più costosi e richiedono molto tempo rispetto ai ripristini di backup dei file. In un pizzico, puoi ripristinare un database più piccolo molto più rapidamente di uno gonfio di immagini. Confronta 1 TB di archiviazione di file in Azure con un database da 1 TB e vedrai la grande differenza di costo.


0

Nella mia esperienza, la memorizzazione nell'URL delle immagini archiviate in un'altra posizione è il modo migliore per un semplice progetto.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.