Respostas:
Dê uma olhada nesta resposta:
Armazenando imagens no banco de dados - sim ou não?
Essencialmente, o impacto no espaço e no desempenho pode ser bastante grande, dependendo do número de usuários. Além disso, lembre-se de que os servidores da Web são baratos e você pode facilmente adicionar mais para equilibrar a carga, enquanto o banco de dados é a parte mais cara e mais difícil de escalar de uma arquitetura da Web normalmente.
Existem alguns exemplos opostos (por exemplo, Microsoft Sharepoint), mas geralmente, armazenar arquivos no banco de dados não é uma boa ideia.
A menos que você crie aplicativos de desktop e / ou saiba aproximadamente quantos usuários você terá, mas em algo tão aleatório e inesperado como um site público, você pode pagar um preço alto por armazenar arquivos no banco de dados.
Se você puder mudar para o SQL Server 2008, poderá aproveitar as vantagens do suporte FILESTREAM, que oferece o melhor de ambos - os arquivos são armazenados no sistema de arquivos, mas a integração do banco de dados é muito melhor do que apenas armazenar um caminho de arquivo em um campo varchar. Sua consulta pode retornar um fluxo de arquivo .NET padrão, o que torna a integração muito mais simples.
Eu diria que depende da sua situação. Por exemplo, eu trabalho no governo local e temos muitas imagens como fotos, etc. Não temos um grande número de usuários, mas precisamos ter uma boa segurança e auditoria em torno dos dados. O banco de dados é uma solução melhor para nós, pois torna isso mais fácil e não vamos ter problemas de dimensionamento.
Qual é a questão aqui?
O DBMS SQL2008 moderno tem uma variedade de maneiras de lidar com BLOBs que não são apenas grudadas em uma tabela. Existem prós e contras, é claro, e talvez você precise pensar um pouco mais a fundo.
Este é um artigo interessante, do falecido (?) Jim Gray
Em minha própria experiência, é sempre melhor armazenar arquivos como arquivos. O motivo é que o sistema de arquivos é otimizado para armazenamento de arquivos, enquanto um banco de dados não é. Claro, existem algumas exceções (por exemplo, o muito proclamado sistema de arquivos MS da próxima geração deve ser construído sobre o servidor SQL), mas em geral essa é a minha regra.
Embora o desempenho seja um problema, acho que os designs modernos de banco de dados o tornaram um problema muito menor para arquivos pequenos.
Deixando de lado o desempenho, isso também depende de quão fortemente acoplados os dados estão. Se o arquivo contiver dados intimamente relacionados aos campos do banco de dados, conceitualmente ele pertence a ele e pode ser armazenado em um blob. Se ele contiver informações que podem estar relacionadas a vários registros ou ter algum uso fora do contexto do banco de dados, ele pertence a fora. Por exemplo, uma imagem em uma página da web é obtida em uma solicitação separada da página que o vincula a ela, portanto, pode pertencer a fora (dependendo do design específico e das considerações de segurança).
Nosso compromisso, e não prometo que seja o melhor, foi armazenar arquivos XML pequenos no banco de dados, mas imagens e outros arquivos fora dele.
Tomamos a decisão de armazenar como varbinary para http://www.freshlogicstudios.com/Products/Folders/ na metade esperando problemas de desempenho. Posso dizer que ficamos agradavelmente surpresos com o quão bem funcionou.
Eu concordo com @ZombieSheep. Só mais uma coisa - geralmente não acho que os bancos de dados realmente precisem ser portáteis porque você perde todos os recursos que seu fornecedor de DBMS oferece. Acho que migrar para outro banco de dados seria a última coisa que se consideraria. Só meus $ 0,02
A sobrecarga de ter que analisar um blob (imagem) em uma matriz de bytes e, em seguida, gravá-la no disco com o nome de arquivo adequado e, em seguida, lê-la é uma sobrecarga suficiente para desencorajá-lo de fazer isso com muita frequência, especialmente se os arquivos forem bastante grande.