Possível duplicado:
Arquivos - no banco de dados ou não?
Eu queria saber se há algum bom motivo para ainda usar campos blob em um banco de dados. Alguns anos atrás eu trabalhei com um banco de dados com um monte de imagens nele, o banco de dados estava muito lento e eu não conseguia ver nenhuma boa razão para manter as imagens dentro do banco de dados, então eu peguei as imagens e armazenei os nomes dos arquivos em vez de.
Essa foi uma jogada inteligente? O que você faria no meu lugar?
Como você pode ver pelas outras respostas, este é um grande "Depende". Alguns outros fatores podem ser se você está pagando pela hospedagem, eles cobram mais pelo armazenamento de arquivos ou armazenamento de banco de dados. O armazenamento de arquivos geralmente é mais barato, especialmente para serviços em nuvem.
Se você for auto-hospedado e estiver usando o SQL Server, a próxima versão, codinome Denali, estenderá o FILESTREAM para permitir acesso via TSQL e sistema de arquivos. Também garantirá que eles permaneçam em sincronia. Você pode acessar, atualizar, excluir de qualquer lado e manterá tudo organizado.
Faça sua pesquisa e descubra o que é importante para você e escolha a direção com base nessa escolha.
A razão para usar BLOBs é simplesmente a capacidade de gerenciamento - você tem exatamente um método para fazer backup e restaurar o banco de dados, você pode facilmente fazer backups incrementais, há risco zero de a imagem e seus metadados armazenados em tabelas de banco de dados ficarem fora de sincronia , você também tem uma interface de programação para executar consultas ou carregar/salvar imagens, portanto, você não precisa fornecer acesso ao sistema de arquivos de clientes remotos e sabe que os mesmos GRANTs serão aplicados às imagens e seus dados associados. Além disso, você tem um método de gerenciamento de armazenamento (por exemplo, no Oracle, você pode colocar tudo no ASM e usar o Oracle como seu LVM para tudo).
Outra aplicação é misturar dados relacionais com objetos serializados (um BLOB pode ser qualquer binário, não precisa ser imagens). Ou você pode executar uma consulta em relação a dados e bytes xy no BLOB, que pode ser um cabeçalho de arquivo, por exemplo. As aplicações são de fato infinitas.
Se o acesso a um BLOB foi mais lento do que o acesso ao seu sistema de arquivos, é altamente provável que seu banco de dados tenha sido configurado incorretamente.
Eu não uso blobs - principalmente de uma perspectiva de backup e restauração, pois não quero que os dados do blob diminuam meus backups.
Eu não armazeno um URL completo, no entanto ... Eu apenas armazeno o caminho do arquivo abaixo de um determinado ponto e construo o caminho, pois tenho mais de uma maneira de pessoas e programas acessarem meus arquivos (FTP, HTTP, diretório local, diretórios montados em NFS).
... claro, eu provavelmente lido com mais e maiores imagens do que a maioria das pessoas ... um dos meus conjuntos de dados recebe cerca de 700 GB de imagens (compactadas) por dia. Mas mesmo as miniaturas dessas imagens, ainda guardo externamente.
Eu sou um grande fã de armazenar a cópia de "referência" da imagem no banco de dados - do ponto de vista de gerenciamento/recuperação de desastres, essa é realmente a maneira de voar.
Agora, você ainda pode fazer muitas coisas para servir a imagem fora do sistema de arquivos para a maioria dos aplicativos, então você não está colocando muita pressão no próprio servidor de banco de dados para fazer coisas que ele realmente não quer fazer.
Se você está trabalhando com linux, armazenar as imagens no sistema de arquivos e não no banco de dados tem um desempenho significativamente melhor, veja este trecho do livro Advanced Rails de Brad Ediger .
Eu não sou muito fã de armazenar imagens no banco de dados. Em um aplicativo pequeno com poucos usuários, parece uma solução fácil, mas à medida que você começa a escalar, torna as coisas mais difíceis.
Minha preferência é começar armazenando as imagens em uma pasta no servidor web, mas manter o caminho em uma configuração de fácil acesso para que, quando eu precisar, possa movê-las rapidamente para seu próprio servidor de imagens dedicado e otimizado. Mais tarde, talvez queira movê-los para outro lugar (pense S3 ou Akamai) da mesma maneira. Tudo isso é muito mais complicado se eu tiver que alterar o código que esperava lê-los do banco de dados.
Se foi uma jogada inteligente ou não, depende do seu caso específico:
Se a localização do arquivo estiver afetando diretamente qualquer estrutura de url ou se você estiver armazenando endereços completos de arquivos no banco de dados (ruim), posso dizer que foi uma má jogada, pois você terá problemas caso alguém mova ou renomeie algum diretório.
Mas como Mas se seu aplicativo for construído de uma maneira que você simplesmente precise apontar o diretório de arquivos e a lógica de acesso ao arquivo for dinâmica, você fez uma jogada inteligente pelos seguintes motivos:
Com o armazenamento em banco de dados, se houver necessidade de atender muitas imagens por solicitação, você aumentará o tempo de resposta de sua aplicação, pois os arquivos serão enviados de forma síncrona para a rede. Além disso, você adicionará um pouco mais de processamento ao seu servidor.
O armazenamento de arquivos geralmente é mais barato que o armazenamento de banco de dados.
Com o armazenamento de arquivos (a menos que haja restrições de acesso às imagens: apenas um determinado usuário pode acessar um determinado grupo de imagens), não há necessidade de nenhum processamento para acessar imagens ou qualquer outro tipo de arquivo.
Com o armazenamento em banco de dados não é possível acessar seus arquivos via FTP (bem óbvio, mas é bom lembrar).
O armazenamento de arquivos de banco de dados diminuirá a velocidade e/ou desordenará seus backups periódicos de banco de dados.
Eu manteria essa decisão a menos que um fator dominante contrário aparecesse.
Espero que ajude.