Il n'y a ni performance ni avantage opérationnel. Depuis SQL 2005, les types LOB sont déjà stocké pour vous par le moteur dans une unité d'allocation séparée, un b-tree séparé. Si vous étudiez le Organisation des tableaux et des index de SQL Server, vous verrez que chaque partition a jusqu'à 3 unités d'allocation :data, LOB et row-overflow :
(source :s-msft.com
)
Un champ LOB (varchar(max), nvarchar(max), varbinary(max), XML, CLR UDT ainsi que les types obsolètes text, ntext et image) n'aura dans l'enregistrement de données lui-même, dans l'index clusterisé, qu'un très faible encombrement :un pointeur dans l'unité d'allocation LOB, voir Anatomie d'un enregistrement .
En stockant un LOB explicitement dans une table séparée vous ne gagnez absolument rien . Vous ajoutez simplement une complexité inutile car les anciennes mises à jour atomiques doivent désormais se répartir dans deux tables distinctes, ce qui complique l'application et la structure des transactions de l'application.
Si le contenu LOB est un fichier entier, vous devriez peut-être envisager de passer à SQL 2008 et d'utiliser FILESTREAM .
