Armazenando Imagens no DB - Sim ou Não?


415

Então, eu estou usando um aplicativo que armazena imagens pesadamente no banco de dados. Qual a sua perspectiva sobre isso? Eu sou mais do tipo que armazena a localização no sistema de arquivos, do que diretamente no banco de dados.

O que você acha que são os prós / contras?


Bem, você pode fazer as duas coisas com um cache de disco transacional .
Lilith River

Respostas:


350

Sou responsável por alguns aplicativos que gerenciam muitos TB de imagens. Descobrimos que armazenar os caminhos de arquivos no banco de dados é o melhor.

Existem alguns problemas:

  • o armazenamento do banco de dados geralmente é mais caro que o armazenamento do sistema de arquivos
  • você pode acelerar o acesso ao sistema de arquivos com produtos de prateleira padrão
    • por exemplo, muitos servidores da Web usam a chamada do sistema sendfile () do sistema operacional para enviar assincronamente um arquivo diretamente do sistema de arquivos para a interface de rede. As imagens armazenadas em um banco de dados não se beneficiam dessa otimização.
  • coisas como servidores da web etc. não precisam de codificação ou processamento especial para acessar imagens no sistema de arquivos
  • os bancos de dados vencem onde a integridade transacional entre a imagem e os metadados é importante.
    • é mais complexo gerenciar a integridade entre os metadados db e os dados do sistema de arquivos
    • é difícil (no contexto de um aplicativo da web) garantir que os dados foram liberados para o disco no sistema de arquivos

33
que produtos disponíveis no mercado estão disponíveis para "super-acelerar" o sistema de arquivos?
Andrei Rînea 04/10/08

22
Embora eu gerencie apenas 3 TB de arquivos, eu definitivamente concordo. Os bancos de dados são para dados estruturados, não blobs.
22409 derobert

7
@derobert: bastante, se você nunca usar um elemento de dados em uma consulta, como condição ou para uma associação, provavelmente não pertence ao banco de dados. Então, novamente, se você tem uma função agradável banco de dados para imagens de consulta para semelhança ...
Nils Weinander

14
que produtos disponíveis no mercado estão disponíveis para "super-acelerar" o sistema de arquivos?
31415 ablmf

5
Re: produtos "super aceleradores": a maioria dos servidores web agora pode tirar proveito da chamada do sistema sendfile () para entregar arquivos estáticos de forma assíncrona para o cliente. Ele transfere para o sistema operacional a tarefa de mover o arquivo do disco para a interface de rede. O sistema operacional pode fazer isso com muito mais eficiência, operando no espaço do kernel. Isso, para mim, parece uma grande vitória para o sistema de arquivos vs. o db para armazenar / exibir imagens.
Alan Donnelly

140

Como na maioria dos problemas, não é tão simples quanto parece. Há casos em que faria sentido armazenar as imagens no banco de dados.

  • Você está armazenando imagens que estão mudando dinamicamente, digamos faturas, e queria obter uma fatura como em 1 de janeiro de 2007?
  • O governo quer que você mantenha 6 anos de história
  • As imagens armazenadas no banco de dados não requerem uma estratégia de backup diferente. As imagens armazenadas no sistema de arquivos não
  • É mais fácil controlar o acesso às imagens se elas estiverem em um banco de dados. Administradores inativos podem acessar qualquer pasta no disco. É preciso um administrador realmente determinado para bisbilhotar em um banco de dados para extrair as imagens

Por outro lado, existem problemas associados

  • Requer código adicional para extrair e transmitir as imagens
  • A latência pode ser mais lenta que o acesso direto a arquivos
  • Carga mais pesada no servidor de banco de dados

2
Não ter uma estratégia de backup separada pode ser um grande problema quando você está escrevendo aplicativos instalados no local (como o SharePoint). Quando você cria um backup do SharePoint, tudo fica no banco de dados, o que facilita muito.
Eric Schoonover

44
A segurança pela obscuridade não é realmente uma estratégia de controle de acesso!
Jon Cage

5
Não acho que ele esteja defendendo a segurança pela obscuridade - ele está dizendo que colocar imagens no banco de dados adiciona outra camada de segurança. (Eu acho ... @Conrad, não quero colocar palavras na sua boca)
AJ.

Eu escolhi o armazenamento de imagens no banco de dados por causa da vantagem de backup único (ou, de maneira geral, com todos os dados em um só lugar), mas os problemas mencionados também são verdadeiros, e é por isso que eu cache as imagens no sistema de arquivos. É o melhor dos dois mundos, e estou surpreso que nenhuma das principais respostas aqui o mencione.
Bart van Heukelom

Por acaso, você está usando a biblioteca ImageResizing.Net para lidar com o cache de imagem de disco SQL->? É o cache de disco mais avançado, escalável e robusto você pode começar ...
Lilith Rio


56

Isso pode ser um tiro no escuro, mas se você estiver usando (ou planejando usar) o SQL Server 2008, recomendo dar uma olhada no novo tipo de dados FileStream .

O FileStream resolve a maioria dos problemas relacionados ao armazenamento dos arquivos no banco de dados:

  1. Os Blobs são realmente armazenados como arquivos em uma pasta.
  2. As gotas podem ser acedidos utilizando quer uma ligação de base de dados ou ao longo do sistema de ficheiros.
  3. Os backups são integrados.
  4. A migração "simplesmente funciona".

No entanto, a "Criptografia de dados transparente" do SQL não criptografa os objetos FileStream, portanto, se isso é uma consideração, é melhor armazená-los como varbinary.

Do artigo do MSDN:

As instruções Transact-SQL podem inserir, atualizar, consultar, pesquisar e fazer backup de dados FILESTREAM. As interfaces do sistema de arquivos Win32 fornecem acesso de streaming aos dados.
FILESTREAM usa o cache do sistema NT para armazenar em cache os dados do arquivo. Isso ajuda a reduzir qualquer efeito que os dados FILESTREAM possam ter no desempenho do Mecanismo de Banco de Dados. O buffer pool do SQL Server não é usado; portanto, essa memória está disponível para processamento de consultas.


+1 para FileStream. Na verdade, ele armazena os blobs como arquivos no disco, mas os gerencia de maneira transacional.
John Gietzen 26/07

Além disso, o SQL Server permite que bolhas FileStream para ser acesso diretamente fora do disco, de modo que você pode evitar amarrar a conexão DB
John Gietzen

Ainda, latência adicionada entre o banco de dados e o servidor da web ... E o servidor da web precisará carregá-lo na memória para transmiti-lo ao cliente, em vez de poder transmiti-lo a partir do disco, a menos que você esteja usando o cache do disco.
Lilith River

39

Os caminhos de arquivo no banco de dados são definitivamente o caminho a percorrer - ouvi histórias e histórias de clientes com TB de imagens de que se tornou um pesadelo tentar armazenar uma quantidade significativa de imagens em um banco de dados - apenas o desempenho atingido é demais.


35

Na minha experiência, às vezes a solução mais simples é nomear as imagens de acordo com a chave primária . Portanto, é fácil encontrar a imagem que pertence a um registro específico e vice-versa. Mas, ao mesmo tempo, você não está armazenando nada sobre a imagem no banco de dados.


Muito bom mesmo. Seus usuários agora podem incrementar facilmente seu nome de arquivo para acessar outros arquivos ...
Marijn Huizendveld 24/10

6
@Marijn: Isso é apenas se você expuser as imagens ao mundo.
Seun Osewa

Fizemos algo muito semelhante aos nossos documentos de imagem (nossa chave primária é uma chave composta de três itens.), Mas adicionamos a data e a hora em que o documento foi digitalizado para que possamos ter várias versões no mesmo diretório.
Andrew Neely

@ Osewa, como é isso? Sim, para acessar diretamente o arquivo, o usuário final precisaria acessar a pasta. Você poderia ter um processo para veicular o arquivo via FTP com base em solicitação, e a segurança estaria no mesmo nível do SQL Server.
Andrew Neely

31

O truque aqui é não se tornar um fanático.

Uma coisa a observar aqui é que ninguém no campo do sistema de arquivos profissional listou um sistema de arquivos específico. Isso significa que tudo, do FAT16 ao ZFS, supera facilmente todos os bancos de dados?

Não.

A verdade é que muitos bancos de dados superam muitos sistemas de arquivos, mesmo quando estamos falando apenas de velocidade bruta.

O curso de ação correto é tomar a decisão certa para o seu cenário preciso e, para isso, serão necessários alguns números e algumas estimativas de casos de uso.


6
Não vejo ninguém afirmando que um sistema de arquivos é mais rápido que um banco de dados 100% do tempo (leia a resposta de Mark Harrison). Isso é meio que um palhaço. Provavelmente, há situações em que é preferível não usar o cinto de segurança, mas de um modo geral , usar um cinto de segurança é uma boa ideia.
Calvin

30

Em locais onde você DEVE garantir integridade referencial e conformidade com ACID, é necessário armazenar imagens no banco de dados.

Você não pode garantir transacionalmente que a imagem e os metadados sobre a imagem armazenada no banco de dados se refiram ao mesmo arquivo. Em outras palavras, é impossível garantir que o arquivo no sistema de arquivos seja alterado apenas ao mesmo tempo e na mesma transação que os metadados.


7
Na verdade, não, você pode. Desde que os arquivos de imagem nunca sejam excluídos, alterados ou substituídos uma vez criados, todos os arquivos de imagem são sincronizados antes de tentar confirmar transações, não há corrupção no sistema de arquivos, você pode ter certeza de que os arquivos de imagem e os metadados estão sincronizados. Para algumas aplicações, esses são muitos ifs, eu acho.
Seun Osewa 5/11/10

Eu diria ainda mais que, com um sistema de arquivos de registro no diário e alguma lógica de programa adicional, a conformidade com o ACID pode ser alcançada. As etapas seriam escrever o registro db, escrever o arquivo. Se o arquivo for confirmado, confirme a transação db.
Andrew Neely

28

Como já foi dito, o SQL 2008 vem com um tipo Filestream que permite armazenar um nome de arquivo ou identificador como um ponteiro no banco de dados e automaticamente armazena a imagem em seu sistema de arquivos, o que é um ótimo cenário.

Se você estiver em um banco de dados mais antigo, eu diria que, se você o estiver armazenando como dados de blob, você realmente não obterá nada do banco de dados na maneira de pesquisar recursos, por isso é provavelmente o melhor para armazenar um endereço em um sistema de arquivos e armazenar a imagem dessa maneira.

Dessa forma, você também economiza espaço no seu sistema de arquivos, pois economiza apenas a quantidade exata de espaço ou até o espaço compactado no sistema de arquivos.

Além disso, você pode optar por salvar com alguma estrutura ou elementos que permitam navegar pelas imagens brutas no sistema de arquivos sem acertos no banco de dados ou transferir os arquivos em massa para outro sistema, disco rígido, S3 ou outro cenário - atualizando o local em seu programa, mas mantenha a estrutura, novamente sem muito sucesso, tentando tirar as imagens do seu banco de dados ao tentar aumentar o armazenamento.

Provavelmente, isso também permitiria que você jogasse algum elemento de cache, com base em URLs de imagens geralmente atingidas, em seu mecanismo / programa da Web, para que você também esteja se salvando.


27

Imagens estáticas pequenas (não mais que alguns megas) que não são editadas com frequência devem ser armazenadas no banco de dados. Esse método possui vários benefícios, incluindo portabilidade mais fácil (imagens são transferidas com o banco de dados), backup / restauração mais fácil (backup de imagens com o banco de dados) e melhor escalabilidade (uma pasta do sistema de arquivos com milhares de pequenos arquivos em miniatura parece um pesadelo de escalabilidade mim).

Servir imagens de um banco de dados é fácil, basta implementar um manipulador http que atenda à matriz de bytes retornada do servidor DB como um fluxo binário.


Eu diria que o banco de dados é melhor para arquivos que são frequentemente editados, pois a consistência pode ser um problema nesse caso.
Seun Osewa 5/11/10

26

Aqui está um white paper interessante sobre o assunto.

BLOB ou Não BLOB: Armazenamento de Objetos Grandes em um Banco de Dados ou em um Sistema de Arquivos

A resposta é "depende". Certamente, isso dependeria do servidor de banco de dados e de sua abordagem ao armazenamento de blob. Também depende do tipo de dados que está sendo armazenado em blobs, bem como de como esses dados devem ser acessados.

Arquivos de tamanho menor podem ser armazenados e entregues com eficiência usando o banco de dados como mecanismo de armazenamento. Arquivos maiores provavelmente seriam melhor armazenados usando o sistema de arquivos, especialmente se forem modificados / atualizados com frequência. (a fragmentação de blob se torna um problema em relação ao desempenho.)

Aqui está um ponto adicional a ser lembrado. Um dos motivos para o uso de um banco de dados para armazenar os blobs é a conformidade com o ACID. No entanto, a abordagem usada pelos testadores no white paper (opção Bulk Logged do SQL Server), que duplicou a taxa de transferência do SQL Server, alterou efetivamente o 'D' no ACID para um 'd', pois os dados do blob não foram registrados com as gravações iniciais da transação. Portanto, se a conformidade total com ACID for um requisito importante para o seu sistema, reduza pela metade os números de taxa de transferência do SQL Server para gravações de banco de dados ao comparar a E / S de arquivo com a E / S do blob do banco de dados.


25

Uma coisa que eu não vi ninguém mencionar ainda, mas definitivamente vale a pena notar, é que também há problemas associados ao armazenamento de grandes quantidades de imagens na maioria dos sistemas de arquivos. Por exemplo, se você adotar a abordagem mencionada acima e nomear cada arquivo de imagem após a chave primária, na maioria dos sistemas de arquivos você terá problemas se tentar colocar todas as imagens em um diretório grande quando atingir um número muito grande de imagens ( por exemplo, nas centenas de milhares ou milhões).

Uma vez que a solução comum para isso é misturá-los em uma árvore equilibrada de subdiretórios.


Você pensaria assim, mas os problemas são realmente menores; Eu tenho um aplicativo com milhões de arquivos em um diretório único, acessado por centenas de usuários, sem problemas. Não é inteligente, mas funciona. O maior problema é que, se você usa o Explorer para navegar no diretório, assiste uma lanterna para sempre.
SqlACID 5/10/08

1
É melhor usar um sistema de arquivos que não tem nenhum problema com grandes diretórios
Seun Osewa

8
Eu tinha um aplicativo com milhões de arquivos em um diretório (servidor executando o RHEL 4) - para listar o conteúdo do diretório (canalizar para um arquivo) levou dias e criei um arquivo de saída com 100 MB de tamanho. Agora eles estão em um banco de dados. Eu tenho um único arquivo que posso mover ou fazer backup com bastante facilidade.
2174 Richard Richard

1
@ Seun Osewa: todo sistema de arquivos tem limitações ... e se você souber de algum que não tenha problemas para armazenar milhões de entradas no mesmo diretório, informe-me!
Guillaume

1
@Seun Osewa: o banco de dados tem até 28 GB agora, com registros de 5,4 M. Eu acabei tendo que particionar a tabela do banco de dados para que eu tenha vários arquivos de backup com aproximadamente 5 GB de tamanho. )
Richard

22

Algo que ninguém mencionou é que o DB garante ações atômicas, integridade transacional e lida com simultaneidade. Mesmo a integridade referencial está fora da janela com um sistema de arquivos - então como você sabe que seus nomes de arquivos ainda estão corretos?

Se você tem suas imagens em um sistema de arquivos e alguém está lendo o arquivo enquanto você está escrevendo uma nova versão ou mesmo excluindo o arquivo - o que acontece?

Usamos blobs porque são mais fáceis de gerenciar (backup, replicação, transferência). Eles funcionam bem para nós.


Qual é a probabilidade de ter duas atualizações simultâneas em uma imagem específica?
Arafangion 09/04/09

1
você não precisa de atualizações simultâneas para ter problemas - pode ser uma leitura e uma gravação. No nosso caso, é quase garantido que isso aconteça.
Draemon

20

O problema de armazenar apenas caminhos de arquivos em imagens em um banco de dados é que a integridade do banco de dados não pode mais ser forçada.

Se a imagem real apontada pelo caminho do arquivo ficar indisponível, o banco de dados sem querer apresenta um erro de integridade.

Dado que as imagens são os dados reais que estão sendo procurados e que eles podem ser gerenciados com mais facilidade (as imagens não desaparecem repentinamente) em um banco de dados integrado, em vez de precisar interagir com algum tipo de sistema de arquivos (se o sistema de arquivos for acessado independentemente, as imagens PODEM "desaparecer" de repente), eu as armazenaria diretamente como um BLOB ou algo assim.


17

Em uma empresa onde eu trabalhava, armazenamos 155 milhões de imagens em um banco de dados Oracle 8i (então 9i). 7.5TB pena.


5
Absolutamente. Aparentemente, o banco de dados é muito maior agora. Ter os dados em um banco de dados significa que replicar o banco de dados em sites diferentes também é muito mais fácil.
23410 Graham.reeds

Eu vi uma demonstração do Oracle, onde ele poderia realmente montar um sistema de arquivos no banco de dados, ou algo assim. Você sabe se foi isso que você fez? (Desculpe, eu sou ignorante com a Oracle lixo então talvez eu estou falando.)
Stu Thompson

Acho que não - estava armazenando imagens no banco de dados como um banco de dados. O banco de dados foi ajustado de forma agressiva - lembro-me de várias discussões sobre o tamanho das imagens alteradas à medida que os campos foram adicionados e removidos. Tudo estava alinhado com os limites.
graham.reeds

14

Normalmente, sou obstinado em pegar a parte mais cara e mais difícil de dimensionar sua infraestrutura (o banco de dados) e colocar toda a carga nela. Por outro lado: simplifica bastante a estratégia de backup, especialmente quando você possui vários servidores da Web e precisa, de alguma forma, manter os dados sincronizados.

Como a maioria das outras coisas, depende do tamanho e do orçamento esperados.


13

Implementamos um sistema de geração de imagens de documentos que armazena todas as suas imagens nos campos de blobs do SQL2005. Existem várias centenas de GB no momento e estamos vendo excelentes tempos de resposta e pouca ou nenhuma degradação de desempenho. Além disso, pela conformidade regulamentar, temos uma camada de middleware que arquiva documentos recém-publicados em um sistema de jukebox óptico que os expõe como um sistema de arquivos NTFS padrão.

Estamos muito satisfeitos com os resultados, principalmente com relação a:

  1. Facilidade de replicação e backup
  2. Capacidade de implementar facilmente um sistema de controle de versão de documentos

11

Se esse for um aplicativo baseado na Web, poderá haver vantagens em armazenar as imagens em uma rede de entrega de armazenamento de terceiros, como o S3 da Amazon ou a plataforma Nirvanix.


11

Suposição: o aplicativo é ativado pela Web / baseado na Web

Estou surpreso que ninguém tenha realmente mencionado isso ... delegue para outros especialistas -> use um provedor de hospedagem de imagem / arquivo de terceiros .

Armazene seus arquivos em um serviço online pago como

Outros threads do StackOverflow falando sobre isso aqui .

Este tópico explica por que você deve usar um provedor de hospedagem de terceiros.

Vale a pena. Eles armazenam de forma eficiente. Nenhuma largura de banda sendo carregada de seus servidores para solicitações de clientes etc.


10

Se você não estiver no SQL Server 2008 e tiver motivos sólidos para colocar arquivos de imagem específicos no banco de dados, poderá adotar a abordagem "ambos" e usar o sistema de arquivos como cache temporário e usar o banco de dados como repositório principal .

Por exemplo, sua lógica de negócios pode verificar se existe um arquivo de imagem no disco antes de servi-lo, recuperando-o do banco de dados quando necessário. Isso oferece a capacidade de vários servidores Web e menos problemas de sincronização.


+1 Isso também permite que você armazene a imagem original, entregando a versão em cache / otimizada e, ao mesmo tempo, alterando o tamanho / compactação posteriormente
Deebster

7

Não sei ao certo qual é o exemplo do "mundo real", mas atualmente tenho um aplicativo que armazena detalhes de um jogo de cartas, incluindo as imagens dos cartões. Concedido que a contagem de registros para o banco de dados é de apenas 2851 registros até a data, mas, como certos cartões foram liberados várias vezes e têm obras de arte alternativas, era realmente mais eficiente digitalizar o "quadrado principal" da arte e, em seguida, dinamicamente gere os efeitos de borda e diversos para o cartão quando solicitado.

O criador original dessa biblioteca de imagens criou uma classe de acesso a dados que renderiza a imagem com base na solicitação e é bastante rápida para visualização e cartão individual.

Isso também facilita a implantação / atualizações quando novos cartões são lançados, em vez de compactar uma pasta inteira de imagens e enviá-las para o canal e garantir a criação da estrutura de pastas adequada, basta atualizar o banco de dados e fazer com que o usuário faça o download novamente. Atualmente, esse tamanho é de até 56 MB, o que não é ótimo, mas estou trabalhando em um recurso de atualização incremental para versões futuras. Além disso, existe uma versão "sem imagens" do aplicativo que permite que os usuários discados obtenham o aplicativo sem o atraso do download.

Esta solução funcionou muito bem até o momento, pois o próprio aplicativo é direcionado como uma única instância na área de trabalho. Existe um site em que todos esses dados são arquivados para acesso on-line, mas eu não usaria a mesma solução para isso. Concordo que o acesso ao arquivo seria preferível, pois seria mais adequado à frequência e ao volume de solicitações feitas pelas imagens.

Espero que isso não seja muito tagarelar, mas eu vi o tópico e queria fornecer algumas idéias de um aplicativo de pequena / média escala relativamente bem-sucedido.


Ao lidar com a replicação, armazenar as imagens no banco de dados é IMO muito superior.
Beep beep


7

Depende do número de imagens que você deseja armazenar e também de seus tamanhos. Eu usei bancos de dados para armazenar imagens no passado e minha experiência tem sido bastante boa.

Na IMO, os profissionais do uso de banco de dados para armazenar imagens são,

A. Você não precisa da estrutura do FS para armazenar suas imagens
B. Os índices do banco de dados têm desempenho melhor que as árvores do FS quando mais itens são armazenados
.
D. Os backups são simples. Também funciona bem se você tiver configurado a replicação e o conteúdo for entregue a partir de um servidor próximo ao usuário. Nesses casos, a sincronização explícita não é necessária.

Se suas imagens forem pequenas (digamos <64k) e o mecanismo de armazenamento do seu banco de dados suportar BLOBs embutidos (registrados), ele aprimora ainda mais o desempenho, pois não é necessário nenhum direcionamento (Localização de referência é alcançada).

Armazenar imagens pode ser uma má idéia quando você está lidando com um pequeno número de imagens de tamanho grande. Outro problema com o armazenamento de imagens no banco de dados é que, como metadados de criação, as datas de modificação devem ser tratadas pelo seu aplicativo.


7

Recentemente, criei um aplicativo PHP / MySQL que armazena arquivos PDF / Word em uma tabela MySQL (até 40 MB por arquivo até agora).

Prós:

  • Os arquivos enviados são replicados para o servidor de backup, juntamente com todo o resto, não sendo necessária nenhuma estratégia de backup separada (tranqüilidade).
  • A configuração do servidor da Web é um pouco mais simples, porque eu não preciso ter uma pasta / uploads e informar todos os meus aplicativos onde ele está.
  • Uso transações para fazer edições para melhorar a integridade dos dados - não preciso me preocupar com arquivos órfãos e ausentes

Contras:

  • O mysqldump agora demora muito, porque há 500 MB de dados de arquivo em uma das tabelas.
  • No geral, não é muito eficiente em termos de memória / CPU quando comparado ao sistema de arquivos

Eu consideraria minha implementação um sucesso, ele cuida dos requisitos de backup e simplifica o layout do projeto. O desempenho é bom para as 20 a 30 pessoas que usam o aplicativo.


6

Na minha experiência, tive que gerenciar as duas situações: imagens armazenadas no banco de dados e imagens no sistema de arquivos com o caminho armazenado no banco de dados.

A primeira solução, imagens no banco de dados, é um pouco "mais limpa", pois sua camada de acesso a dados precisará lidar apenas com objetos de banco de dados; mas isso é bom apenas quando você precisa lidar com números baixos.

Obviamente, o desempenho do acesso ao banco de dados quando você lida com objetos binários grandes é degradante, e as dimensões do banco de dados aumentam muito, causando novamente uma perda de desempenho ... e normalmente o espaço no banco de dados é muito mais caro que o espaço no sistema de arquivos.

Por outro lado, ter objetos binários grandes armazenados no sistema de arquivos fará com que você tenha planos de backup que precisam considerar o banco de dados e o sistema de arquivos, e isso pode ser um problema para alguns sistemas.

Outro motivo para optar pelo sistema de arquivos é quando você precisa compartilhar os dados de suas imagens (ou sons, vídeo, o que for) com acesso de terceiros: atualmente, estou desenvolvendo um aplicativo da web que usa imagens que precisam ser acessadas de "fora" "meu web farm de tal maneira que um acesso ao banco de dados para recuperar dados binários é simplesmente impossível. Às vezes, também existem considerações de design que o levarão a uma escolha.

Considere também, ao fazer essa escolha, se você precisar lidar com permissão e autenticação ao acessar objetos binários: esses requisitos normalmente podem ser resolvidos de uma maneira mais fácil quando os dados são armazenados em db.


4

Certa vez, trabalhei em um aplicativo de processamento de imagens. Armazenamos as imagens carregadas em um diretório semelhante a / images / [data de hoje] / [número de identificação]. Mas também extraímos os metadados (dados exif) das imagens e os armazenamos no banco de dados, junto com um carimbo de data e hora e tal.


4

Em um projeto anterior, armazenei imagens no sistema de arquivos e isso causou muitas dores de cabeça com backups, replicação e sistema de arquivos ficando fora de sincronia com o banco de dados.

No meu projeto mais recente, estou armazenando imagens no banco de dados e armazenando em cache no sistema de arquivos, e funciona muito bem. Até agora não tive problemas.


3

Segundo a recomendação sobre caminhos de arquivo. Trabalhei em alguns projetos que precisavam gerenciar grandes coleções de ativos e quaisquer tentativas de armazenar coisas diretamente no banco de dados resultaram em dor e frustração a longo prazo.

O único "profissional" real em que posso pensar em armazená-los no banco de dados é o potencial para facilitar os ativos de imagem individuais. Se não houver caminhos de arquivo a serem usados ​​e todas as imagens forem transmitidas diretamente do banco de dados, não há perigo de um usuário encontrar arquivos aos quais não deve ter acesso.

Isso parece que seria melhor resolvido com um script intermediário que extraía dados de um armazenamento de arquivos inacessível pela Web. Portanto, o armazenamento do banco de dados não é REALMENTE necessário.


3

A palavra na rua é que, a menos que você seja um fornecedor de banco de dados tentando provar que seu banco de dados pode fazê-lo (como, digamos, a Microsoft se vangloriando do Terraserver armazenando um bajilhão de imagens no SQL Server), não é uma idéia muito boa. Quando a alternativa - armazenar imagens em servidores de arquivos e caminhos no banco de dados é muito mais fácil, por que se preocupar? Os campos de blob são como os recursos off-road dos SUVs - a maioria das pessoas não os usa, aqueles que geralmente se metem em problemas e depois há quem o faça, mas apenas por diversão.


3

O armazenamento de uma imagem no banco de dados ainda significa que os dados da imagem acabam em algum lugar do sistema de arquivos, mas são obscurecidos, para que você não possa acessá-los diretamente.

+ ves:

  • integridade do banco de dados
  • é fácil de gerenciar, pois você não precisa se preocupar em manter o sistema de arquivos sincronizado quando uma imagem é adicionada ou excluída

-ves:

  • penalidade de desempenho - uma pesquisa no banco de dados geralmente é mais lenta que uma pesquisa no sistema de arquivos
  • você não pode editar a imagem diretamente (cortar, redimensionar)

Ambos os métodos são comuns e praticados. Veja as vantagens e desvantagens. De qualquer forma, você terá que pensar em como superar as desvantagens. Armazenar no banco de dados geralmente significa ajustar os parâmetros do banco de dados e implementar algum tipo de cache. O uso do sistema de arquivos requer que você encontre uma maneira de manter o sistema de arquivos + o banco de dados sincronizados.

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.