Problemas con el tipo de dato Table

El tipo de dato «table», es utilizado también como un espacio temporal de almacenamiento de registros con un comportamiento similar a una tabla común y corriente.

DECLARE @MyTable table

Es muy común y muchas veces utilizado como una tabla temporal. Lo que no todos saben es que existen problemas con el tipo de dato Table en el diseño.

LIMITACIONES: Origen de problemas con el tipo de dato Table

Lo primero que tienes que hacer es entender que hay aspectos técnicos y conceptuales que deben ser considerados al usar este mecanismo en la programación.

Vamos a ver algunos.

¡No tienen distribución de estadísticas!

Tal vez el peor de los problemas. Al no generar estadísticas, el optimizador del motor asumirá que una variable Table no tiene registros en ella, o sea que no tiene ninguna fila. Es así que en la propiedad «Número estimado de filas» (Estimated number of rows) del plan de ejecución, asumirá a 1 fila en la tabla. En versiones más recientes de SQL Server esta estimación cambió a 100.

Imagínate una variable tabla con millones de registros que siempre sea estimado a 1 registro, o a 100. Una estimación muy alejada de la realidad verdad? Esto hace que el optimizador tome malas decisiones que se traducen en pobre performance. (Para entender mejor estos conceptos puedes leer acerca del Cardinality Estimator)

¡No son parte persistente de la base de datos!

Esto hace que no sean consideradas del todo como una transacción ya que tampoco son afectadas como parte del proceso de ROLLBACK.

Declaramos una variable de tipo tabla y la consultamos para probar que su contenido está vacío.

DECLARE @HateList TABLE
	(Hate varchar(20))

SELECT * FROM @HateList

Ahora bien, insertemos registros a la tabla dentro de una transacción explícita y apliquemos un ROLLBACK.

BEGIN TRAN
	INSERT INTO @HateList values
	('QueryPerformance'),
	('IndexesUsage'),
	('QualityControl'),
	('Documentation')
ROLLBACK

SELECT * FROM @HateList

¿Qué debería suceder con el SELECT después del ROLLBACK?

Veamos el resultado…

¿No era acaso que el INSERT iba a ser parte de un proceso de ROLLBACK? Démos una mirada otra vez. Pues resulta que sí, pero al insertar registros dentro de una variable tipo TABLE, el ROLLBACK no tiene ningún efecto.

¿Quieres este comportamiento en tus transacciones? Yo creo que no. (Al menos eso espero). No olvides estos problemas con el tipo de dato Table para tus diseños en SQL Server.

Mira también una comparación entre tablas temporales y variables de tipo tabla.

¿Tú crees que este es el único problema con las variables tablas? Mira Por qué la variable tabla no usa paralelismo.

También puedes ver cómo Mejorar las variables tabla con Table Deferred Compilation.