No hay rendimiento ni ventaja operativa. Desde SQL 2005, los tipos LOB ya almacenado para usted por el motor en una unidad de asignación separada, un árbol b separado. Si estudia el Organización de tablas e índices de SQL Server, verá que cada partición tiene hasta 3 unidades de asignación:datos, LOB y desbordamiento de fila:
(fuente:s-msft.com
)
Un campo LOB (varchar(max), nvarchar(max), varbinary(max), XML, CLR UDT, así como los tipos obsoletos text, ntext e image) tendrán en el registro de datos en sí, en el índice agrupado, solo un huella muy pequeña:un puntero a la unidad de asignación de LOB, consulte Anatomía de un registro .
Al almacenar un LOB explícitamente en una tabla separada no gana absolutamente nada . Simplemente agrega complejidad innecesaria, ya que las actualizaciones atómicas anteriores tienen que distribuirse ahora en dos tablas separadas, lo que complica la aplicación y la estructura de transacciones de la aplicación.
Si el contenido LOB es un archivo completo, quizás debería considerar actualizar a SQL 2008 y usar FLUJO DE ARCHIVO .
