Pergunta

Eu estou adicionando algumas funcionalidades para o meu site para que os usuários podem fazer upload de suas próprias fotos de perfil, então eu estava me perguntando sobre a possibilidade de armazená-los no banco de dados como um BLOB, ou colocá-los no sistema de arquivos.

Eu encontrei uma pergunta semelhante a esta aqui: armazenar imagens em DB: Sim ou Nay , mas as respostas dadas foram mais orientadas para as pessoas que esperam muitos milhares ou mesmo milhões de imagens, enquanto eu estou mais preocupado com pequenas imagens (JPEGs de até talvez 150x150 pixels), e um pequeno número de-los: talvez até um ou dois mil.

Quais são os sentimentos sobre DB BLOB vs Sistema de Arquivos para esse cenário? Como os clientes ir com cache de imagens a partir do DB vs do sistema de arquivos?

Se BLOBs armazenados no DB são o caminho a percorrer - há algo que eu deveria saber sobre , onde para armazená-los? Desde que eu imagino que a maioria dos meus usuários não serão upload de uma foto, eu deveria criar uma tabela user_pics a (exterior) juntar-se à mesa users regular quando necessário?


Edit: Eu estou reabrindo essa questão, porque é não uma duplicata dos dois você vinculado. Esta questão é especificamente sobre as vantagens / desvantagens de usar um DB ou FS para um pequeno número de imagens. Como eu disse acima, a outra questão é voltado para pessoas que precisam armazenar milhares e milhares de imagens grandes.

Foi útil?

Solução

Para partes resposta de sua pergunta:

Como os clientes ir com cache de imagens a partir do DB vs do sistema de arquivos?

Para um banco de dados: Tenha um campo last_modified em seu banco de dados. Use o Last-Modified cabeçalho HTTP de modo navegador do cliente pode armazenar em cache corretamente. Certifique-se de enviar as respostas adequadas quando as solicitações do navegador para uma imagem "if newer" (não me lembro o que é chamado, algumas cabeçalho de solicitação HTTP).

Para um sistema de arquivos:. Faça a mesma coisa, mas com o tempo modificado do arquivo

Se BLOBs armazenados no DB são o caminho a percorrer - há algo que eu deveria saber sobre onde armazená-los? Desde que eu imagino que a maioria dos meus usuários não serão upload de uma foto, eu deveria criar uma tabela user_pics a (exterior) juntar-se à mesa de usuários regulares quando necessário?

Eu colocaria o BLOB e metadados relacionados em sua própria mesa, com algum tipo de relação entre ele e sua tabela de usuário. Fazendo isso irá tornar mais fácil para otimizar o método de armazenamento da tabela para os seus dados, torna as coisas mais claras, e deixa espaço para expansão (geral "Arquivos", por exemplo, uma tabela).

Outras dicas

Uma vez eu enfrentou uma pergunta semelhante com um pequeno DMS para arquivos PDF. O cenário era diferente da sua: Um máximo de pode ser de 100 arquivos com tamanhos de até 10 MB cada - não o que você espera para fotos de perfil. Mas a resposta que um amigo me deu de volta, em seguida, se aplica ao seu caso, bem como:

Use cada sistema de armazenamento para o que é projetado para fazer.

Loja dados em banco de dados . LOJA arquivos em sistema de arquivos .

Esta não é a resposta final (*), mas é uma boa regra de ouro para começar.

Eu nunca ouvi falar de Windows FS sendo lento e por vezes pouco fiáveis, como Aaron Digulla afirma em sua resposta. Se houver tais problemas, isso certamente deve ser tido em. Mas para avatar imagens, não me parece importante.

(*) Eu sei, eu sei, 42 ...

O que seria mais conveniente, a partir da perspectiva de servi-los, escrever o código para servi-los, procedimentos de backup, etc.? Você quer a resposta certa para você, não é a resposta certa para outra pessoa.

Do meu ponto de vista tudo o que pode estar fora esquerdo do banco de dados deve ficar de fora. Pode ser sistema de arquivos ou mesas separadas que você não replicar ou de backup a cada dia. Faz banco de dados muito mais leve, ela cresce mais lento e mais fácil de entender e manter.

Se você estiver em MSSQL make certeza que bolhas são armazenados no arquivo de dados separado. Não em primárias como tudo o resto.

No Windows, coloque o máximo que puder na base de dados. O sistema de arquivos é um pouco lento e às vezes até pouco fiáveis.

No Linux, você tem mais opções. Aqui, você deve considerar mover grandes arquivos em um sistema de arquivos e manter apenas o nome do DB. Se você usar um sistema de arquivos moderno, como Ext3 ou ReiseFS, você mesmo pode criar muitos arquivos pequenos com um desempenho muito bom.

Você também precisa levar em conta a forma como você pode acessar os dados. Se você tem tudo no DB, você tem um caminho de acesso, não precisa se preocupar com um outro conjunto de permissões, mas você tem que lidar com a complexidade extra de leitura / escrita BLOBs. Em muitos bancos de dados, BLOBs não pode ser pesquisado.

No sistema de arquivos, você pode executar outras ferramentas em seus dados que não é possível se os arquivos são armazenados em um DB.

Gostaria de armazená-los no banco de dados:

  1. Backup / restore é fácil (se você arquivos de backup e também o banco de dados, point-in-time recuperação é mais complicado)
  2. Movimentações no db significa que você nunca deve acabar apontando para um nome de arquivo que não existe
  3. Menos chance de que alguém vai descobrir uma maneira sorrateira de colocar um script em seu servidor através de uma imagem desonesto carregamento corte

Uma vez que você está falando sobre um pequeno número de imagens, facilidade de uso / administração deve tomar preferência sobre problemas de desempenho que são debatidos nas questões ligadas.

Eu acho que há uma vantagem managability armazená-los no banco de dados; eles podem ser copiados e restaurados de forma consistente com os outros dados - você não se esqueça de apagar os obsoletos (bem, você pode, mas é um pouco menos provável), e se você migrar o banco de dados para outra máquina, as imagens ir com -lo.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top