Няма производителност, нито оперативно предимство. От SQL 2005 типовете LOB са вече съхранявани за вас от двигателя в отделна единица за разпределение, отделно b-дърво. Ако изучавате Организация на таблици и индекси на SQL Server ще видите, че всеки дял има до 3 единици за разпределение:данни, LOB и препълване на редове:
(източник:s-msft.com
)
LOB поле (varchar(max), nvarchar(max), varbinary(max), XML, CLR UDT, както и отхвърлените типове text, ntext и image) ще има в самия запис на данни, в клъстерирания индекс, само a много малък отпечатък:указател към единицата за разпределение на LOB, вижте Анатомия на запис .
Като съхранявате LOB изрично в отделна таблица не печелите абсолютно нищо . Вие просто добавяте ненужна сложност, тъй като предишните атомарни актуализации трябва сега да се разпределят в две отделни таблици, усложнявайки приложението и структурата на транзакцията на приложението.
Ако съдържанието на LOB е цял файл, тогава може би трябва да помислите за надграждане до SQL 2008 и използване на FILESTREAM .
