Para saber por que isso é feio, você precisa saber como um banco de dados é salvo no disco rígido (especificamente linhas). O conteúdo físico de uma linha salva no disco é dividido em seus equivalentes estáticos e dinâmicos. Campos como int, byte, char (n) com comprimento fixo são listados primeiro. O que se segue é um número de comprimento fixo que se refere ao número de campos de comprimento variável a seguir. Todos os campos variáveis (independentemente da ordem das colunas apresentadas a você, o programador) são adicionados no final, cada um com um número de comprimento fixo, que determina quanto espaço o campo de comprimento variável ocupa.
Para dar um exemplo concreto. Suponha que minha tabela seja a seguinte:
char(3) A
varchar(4) B
int C
Agora suponha que sim INSERT INTO mytable (A, B, C) VALUES ('AAA', 'B', 256). No banco de dados, essa linha provavelmente seria armazenada da seguinte maneira:
O campo A é salvo conforme o esperado. Se eu tivesse inserido 'A', ele forneceria um caractere especial para marcar o final prematuro da sequência após o primeiro caractere, mas ocuparia o mesmo espaço.
O campo C é salvo como o equivalente binário de 256. Por que C e não B? C é o próximo campo estático com comprimento fixo e, como tal, é agrupado com todos os outros dados estáticos na linha do banco de dados.
O campo D é uma meta-informação para o banco de dados, que indica que na seção de campos de comprimento variável a seguir, haverá precisamente 1 campo.
O campo E é novamente uma meta-informação para o banco de dados, que indica que, para esse campo em particular, tem no máximo 1 caractere. Essas informações são essenciais porque, caso contrário, o banco de dados não saberia onde o campo B termina e outro campo de comprimento variável começa.
Tudo isso para demonstrar como os bancos de dados lidam com o salvamento de campos de tamanho variável. BLOB é um campo de tamanho variável para esse efeito. A estrutura do banco de dados permite que uma linha contenha valores pequenos e grandes no BLOB, no entanto, existem outros fatores em jogo aqui. Os bancos de dados normalmente lidam com pedaços de informações, pois os discos não se importam com o conteúdo, mas se eles se encaixam em um único pedaço.
O banco de dados tentará ajustar o número de linhas em um único pedaço sem precisar separar uma linha em duas partes, porque, caso contrário, o efeito é o mesmo que ter um arquivo fragmentado no disco rígido. Depois que um pedaço é carregado, se a linha ultrapassar esse pedaço específico, o disco rígido deve procurar o restante em outro pedaço. Pior ainda, não há como um banco de dados saber que uma linha ocupa mais de um pedaço sem ler completamente seu conteúdo, uma vez que é de tamanho variável; portanto, não é possível otimizar buscando os dois pedaços de uma só vez.
Seguindo essa linha de lógica, se você pudesse criar um BLOB de comprimento estático, não teria esse problema de otimização, pois o banco de dados poderia simplesmente garantir que o tamanho do pedaço fosse maior que o tamanho mínimo da linha, garantindo assim que a maioria das linhas não precisa ser dividido em vários pedaços. Obviamente, os bancos de dados não fazem isso porque significariam dedicar um espaço precioso quando você provavelmente não precisará dele.
BLOBS são bons quando você está lidando com quantidades relativamente pequenas, mas para arquivos grandes, como vídeos e similares, uma solução comum é simplesmente salvar o caminho do arquivo no banco de dados e deixar o software lidar com o carregamento do arquivo, quase sempre mais eficiente.
Espero que isso explique. :)