Non ci sono prestazioni né vantaggi operativi. Da SQL 2005 i tipi LOB sono già memorizzato per te dal motore in un'unità di allocazione separata, un b-tree separato. Se studi Organizzazione di tabelle e indici di SQL Server vedrai che ogni partizione ha fino a 3 unità di allocazione:dati, LOB e overflow di riga:
(fonte:s-msft.com
)
Un campo LOB (varchar(max), nvarchar(max), varbinary(max), XML, CLR UDT nonché i tipi deprecati text, ntext e image) avrà nel record di dati stesso, nell'indice cluster, solo un ingombro molto ridotto:un puntatore all'unità di allocazione LOB, vedere Anatomia di un record .
Memorizzando un LOB in modo esplicito in una tabella separata non guadagni assolutamente nulla . Aggiungi semplicemente complessità non necessaria poiché i precedenti aggiornamenti atomici devono distribuirsi ora in due tabelle separate, complicando l'applicazione e la struttura delle transazioni dell'applicazione.
Se il contenuto LOB è un intero file, forse dovresti prendere in considerazione l'aggiornamento a SQL 2008 e l'utilizzo di FILESTREAM .
