Nie ma wydajności ani przewagi operacyjnej. Od SQL 2005 typy LOB są już przechowywane dla Ciebie przez silnik w oddzielnej jednostce alokacji, osobnym b-drzewo. Jeśli zapoznasz się z Organizacja tabel i indeksów SQL Server zobaczysz, że każda partycja ma do 3 jednostek alokacji:danych, LOB i przepełnienia wierszy:
(źródło:s-msft.com
)
Pole LOB (varchar(max), nvarchar(max), varbinary(max), XML, CLR UDTs, a także przestarzałe typy text, ntext i image) będą miały w samym rekordzie danych, w indeksie klastrowym, tylko bardzo mały ślad:wskaźnik do jednostki alokacji LOB, patrz Anatomia rekordu .
Przechowując LOB jawnie w osobnej tabeli nie zyskasz absolutnie nic . Po prostu dodajesz niepotrzebną złożoność, ponieważ poprzednie aktualizacje atomowe muszą teraz dystrybuować się do dwóch oddzielnych tabel, komplikując aplikację i strukturę transakcji aplikacji.
Jeśli zawartość LOB jest całym plikiem, być może powinieneś rozważyć uaktualnienie do SQL 2008 i użycie ŚCIEŻNIK PLIKÓW .
