Embora relacionado a esta questão, tenho um ângulo ligeiramente diferente para abordar esta questão. Aqui está a minha situação:
Estou escrevendo um aplicativo da Web (em PHP ou Python) que gerencia complementos para um aplicativo de desktop. Os usuários podem procurar complementos, instalá-los, carregá-los, etc.
Estou planejando o esquema para o banco de dados e me deparei com uma decisão a tomar:
É melhor armazenar ícones (para os complementos) na própria tabela ou, em vez disso, armazená-los no sistema de arquivos e simplesmente armazenar um nome de arquivo na tabela?
Os ícones são pequenos (48x48 ou próximo disso) e provavelmente não ocuparão mais do que 5 ou 6 KB no máximo. Há alguma desvantagem séria em armazenar os dados da imagem na tabela? Existem outras implicações das quais eu deveria estar ciente? O desempenho será uma preocupação? O armazenamento será um problema?
Edit: Atualmente, estou olhando para tabelas MyISAM em um banco de dados MySQL.
Você não especificou a plataforma de banco de dados que está considerando, mas neste tamanho/escala, é improvável que faça diferença.
5kb por registro é trivial. 1 milhão de registros de 5 KB é < 5 GB, ainda trivial. 10 milhões de registros de 5kb... ainda não é algo para perder o sono.
Se quiséssemos obter uma plataforma específica, um white paper normalmente exaustivamente pesquisado por Paul Randall sobre o armazenamento de fluxo de arquivos do SQL Server sugere que ele supera o armazenamento de tabelas em que os arquivos têm 1 MB ou mais. Tamanhos de arquivo abaixo de 1 MB, os pontos positivos são principalmente em torno do fluxo de arquivos ignorando o buffer pool.
Os pontos positivos para armazenamento de banco de dados:
Edit: Os negativos (como sugerido por Aaron)
Outro aspecto interessante que torna o armazenamento de dados de imagem bastante desafiador é ter o tamanho de pacote correto. Falei sobre isso em 27 de abril de 2011 .
Como as imagens devem ser armazenadas em campos BLOB, haverá operações internas e/ou comunicações externas de dados BLOB por meio de programas (como mysqldump), infraestrutura (como MySQL Replication) e uso de consulta geral (como ter dados BLOB em tabelas temporárias internas durante JOINs e avaliação da cláusula WHERE).
Além disso, conforme mencionado na URL anterior, o mecanismo de armazenamento InnoDB tem uma maneira de lidar com pacotes na memória e arquivos de log.
Não deve ser esquecido é construir consultas SQL que
À luz desses fatos, você terá que configurar my.cnf com um número para max_allowed_packet para que um único pacote MySQL seja grande o suficiente para acomodar múltiplos BLOBs. Você também deve procurar ter RAM disponível suficiente no servidor de banco de dados. Caso contrário, lidar com BLOBs em massa, movendo constantemente um único BLOB para dentro e para fora de um pacote, produzirá gargalos de desempenho inesperados.
CONCLUSÃO
A maioria das considerações/desvantagens devem se anular uma vez que você tenha RAM disponível suficiente, pacotes MySQL de tamanho adequado e consultas que evitem o acúmulo de dados BLOB em várias tabelas temporárias.
ATUALIZAÇÃO 2011-09-09 12:23 EDT
Outra consideração é lembrar de usar a opção --hex-blob no mysqldump. Caso contrário, pode tornar as coisas um pouco difíceis de recarregar o blob, dependendo de certas sequências de caracteres.