Armazenando imagens no SQL Server?


191

Criei um pequeno site de demonstração e nele estou armazenando imagens em uma coluna de imagem no servidor sql. Algumas perguntas que tenho são ...

  • Isso é uma má ideia?

  • Isso afetará o desempenho do meu site quando crescer?

A alternativa seria armazenar a imagem no disco e armazenar apenas a referência à imagem no banco de dados. Este deve ser um dilema comum que muitas pessoas tiveram. Eu gostaria de receber alguns conselhos e ficaria feliz em cometer menos erros, se eu pudesse.


5
Existe alguma nova adição para esse problema em 2017? Isso ainda é válido a partir de hoje?
Haikal Nashuha

Respostas:


270

Existe um artigo realmente bom da Microsoft Research chamado To Blob ou Not To Blob .

Sua conclusão após um grande número de testes e análises de desempenho é a seguinte:

  • se suas fotos ou documentos tiverem normalmente menos de 256 KB de tamanho, armazená-los em uma coluna VARBINARY do banco de dados será mais eficiente

  • se suas fotos ou documentos geralmente têm mais de 1 MB, armazená-los no sistema de arquivos é mais eficiente (e com o atributo FILESTREAM do SQL Server 2008, eles ainda estão sob controle transacional e fazem parte do banco de dados)

  • entre os dois, é um pouco complicado dependendo do seu uso

Se você decidir colocar suas fotos em uma tabela do SQL Server, recomendo o uso de uma tabela separada para armazenar essas fotos - não armazene a foto do funcionário na tabela de funcionários - mantenha-as em uma tabela separada. Dessa forma, a tabela Employee pode permanecer enxuta, mesquinha e muito eficiente, supondo que você nem sempre precise selecionar a foto do funcionário, como parte de suas consultas.

Para grupos de arquivos, consulte Arquitetura de arquivos e grupos de arquivos de para obter uma introdução. Basicamente, você pode criar seu banco de dados com um grupo de arquivos separado para grandes estruturas de dados desde o início ou adicionar um grupo de arquivos adicional posteriormente. Vamos chamá-lo de "LARGE_DATA".

Agora, sempre que houver uma nova tabela para criar, que precisa armazenar as colunas VARCHAR (MAX) ou VARBINARY (MAX), você pode especificar este grupo de arquivos para os dados grandes:

 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

Confira a introdução do MSDN nos grupos de arquivos e brinque com ela!


Isso é bom ou ruim ... • se suas fotos ou documentos tiverem normalmente mais de 1 MB de tamanho, armazená-los no sistema de arquivos é mais eficiente (e com o atributo FILESTREAM do SQL Server 2008, eles ainda estarão sob controle transacional e parte do banco de dados)
htm11h

Ótima resposta. Se você sentir como explicar em detalhes por que você recomendaria para usar uma tabela dedicada para dados de imagem, tenho criado uma questão separada para que em dba.SE .
Heinzi

15

Caí nesse dilema uma vez e pesquisei bastante no google para obter opiniões. O que eu descobri foi que, de fato, muitos vêem salvar imagens em disco melhor para imagens maiores, enquanto o mySQL permite um acesso mais fácil, especialmente de linguagens como PHP.

Encontrei uma pergunta semelhante

MySQL BLOB vs arquivo para armazenar pequenas imagens PNG?

Meu veredicto final foi que, para coisas como uma foto de perfil, apenas uma pequena imagem quadrada que precisa estar lá por usuário, o mySQL seria melhor do que armazenar vários polegares no disco rígido, enquanto para álbuns de fotos e coisas assim, pastas / arquivos de imagem são melhores.

Espero que ajude


14

Eu preferiria armazenar a imagem em um diretório e, em seguida, armazenar uma referência ao arquivo de imagem no banco de dados.

No entanto, se você armazenar a imagem no banco de dados, particione o banco de dados para que a coluna da imagem resida em um arquivo separado.

Você pode ler mais sobre o uso de grupos de arquivos aqui http://msdn.microsoft.com/en-us/library/ms179316.aspx .


11

Por que pode ser bom armazenar imagens no banco de dados e não em um catálogo no servidor da web.

Você fez um aplicativo com muitas fotos armazenadas em uma pasta no servidor que o cliente usa há anos.

Agora eles vêm até você. O servidor foi destruído e eles precisam restaurá-lo em um novo servidor. Eles não têm mais acesso ao servidor antigo. O único backup que eles têm é o backup do banco de dados.

Naturalmente, você possui a fonte e pode implantá-la no novo servidor, instalar o SqlServer e restaurar o banco de dados. Mas agora todas as fotos se foram.

Se você salvou as imagens no SqlServer, tudo funcionará como antes.

Apenas meus 2 centavos.


3
Bom ponto. Os backups das imagens são tão importantes quanto o backup do banco de dados ... algumas vezes ainda mais.
22417 Chris Cornignani

As imagens no sistema de arquivos também precisam de permissões de rede.
22617 Chris Chrisignignani

2
Permissões de rede é um bom ponto. Mas não vejo um caso em que você tenha apenas um backup do banco de dados. Você certamente teria um backup do aplicativo e dos arquivos. Você poderia facilmente perder o banco de dados, mas ter os arquivos.
Norbert Norbertson



7

Embora os problemas de desempenho sejam válidos, os motivos reais na prática de evitar o armazenamento de imagens em um banco de dados são por razões de gerenciamento de banco de dados. Seu banco de dados aumentará muito rapidamente e os bancos de dados custam muito mais que o simples armazenamento de arquivos. Os backups e restaurações de bancos de dados são muito mais caros e demorados do que as restaurações de backup de arquivos. Em uma pitada, você pode restaurar um banco de dados menor muito mais rapidamente do que um inchado com imagens. Compare 1 TB de armazenamento de arquivos no Azure a um banco de dados de 1 TB e você verá a grande diferença de custo.


0

Na minha experiência, armazenar na URL as imagens armazenadas em outro local é a melhor maneira de um projeto simples.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.