Não há desempenho nem vantagem operacional. Desde o SQL 2005 os tipos LOB já são armazenados para você pelo mecanismo em uma unidade de alocação separada, uma b-tree separada. Se você estudar o Organização de tabelas e índices do SQL Server você verá que cada partição tem até 3 unidades de alocação:data, LOB e row-overflow:


_{(fonte:s-msft.com )}

Um campo LOB (varchar(max), nvarchar(max), varbinary(max), XML, CLR UDTs bem como os tipos obsoletos text, ntext e image) terá no próprio registro de dados, no índice clusterizado, apenas um pegada muito pequena:um ponteiro para a unidade de alocação LOB, consulte Anatomia de um registro .

Ao armazenar um LOB explicitamente em uma tabela separada, você não ganha absolutamente nada . Você apenas adiciona complexidade desnecessária, pois as atualizações atômicas anteriores precisam se distribuir agora em duas tabelas separadas, complicando o aplicativo e a estrutura de transação do aplicativo.

Se o conteúdo do LOB for um arquivo inteiro, talvez você deva considerar atualizar para o SQL 2008 e usar FILESTREAM .