El uso de tipos de datos definidos por el usuario (UDTs) en una base de datos tiene dos ventajas principales. En primer lugar, para columnas que deben tener el mismo tipo de datos y se comparan o se unen, el uso del mismo UDT garantiza la compatibilidad. En segundo lugar, los UDTs se pueden utilizar para obtener una lista de todas las columnas del mismo tipo específico, como un número de identificación, mediante la visualización de las dependencias del UDT.

Existe la creencia entre los desarrolladores y administradores de bases de datos de SQL Server de que los UDTs pueden degradar el rendimiento. En este artículo, investigaremos si esta creencia es verdadera o falsa.

Para probar las implicaciones de rendimiento de los UDTs en una base de datos, creamos dos bases de datos idénticas. Ambas bases de datos contienen el mismo esquema y datos, siendo la única diferencia que una base de datos utiliza tipos de datos nativos y la otra solo utiliza UDTs.

Para nuestras pruebas, decidimos utilizar la base de datos de ejemplo AdventureWorks, proporcionada por Microsoft. Creamos dos bases de datos: AdventureWorks y AdventureWorks_2. En AdventureWorks_2, creamos UDTs adicionales y modificamos todas las columnas de todas las tablas del esquema [Sales] para utilizar solo UDTs.

A continuación se muestra un ejemplo de una tabla en el esquema Sales, utilizando los UDTs recién creados:

CREATE TABLE [Sales].[Customer_2](
[Customer_2ID] [dbo].[u_KEY] NOT NULL,
[TerritoryID] [dbo].[u_KEY] NULL,
[AccountNumber] dbo.AccountNumber null,
[Customer_2Type] [nchar](1) NOT NULL,
[rowguid] [dbo].[u_rowguid] NOT NULL,
[ModifiedDate] [dbo].[u_Datetime] NOT NULL,
CONSTRAINT [PK_Customer_2_Customer_2ID] PRIMARY KEY CLUSTERED 
   ([Customer_2ID] ASC
   )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
   ) ON [PRIMARY]

Además, creamos 100 UDTs aleatorios adicionales en AdventureWorks_2, solo para agregar más sobrecarga a la tabla sys.systypes, que contiene los tipos de datos nativos y los UDTs.

Luego comparamos el rendimiento de los mismos comandos SELECT, INSERT, UPDATE y DELETE entre las dos bases de datos. La comparación fue capturada por el Profiler.

Los resultados de nuestras pruebas no mostraron ninguna correlación entre el uso de UDTs y la degradación del rendimiento. Las estadísticas IO mostraron que el número de páginas en las tablas Customer y Customer_2 era el mismo en ambas bases de datos.

También ejecutamos los mismos comandos varias veces y promediamos los resultados del Profiler. La CPU promedio, las lecturas, las escrituras y la duración fueron muy similares entre las dos bases de datos.

Según estos resultados, parece que no hay sobrecarga ni implicaciones de rendimiento al utilizar UDTs en SQL Server. El optimizador de SQL Server utiliza el system_type_id, y la existencia de un user_type_id diferente es solo para fines de administración de bases de datos.

En conclusión, el uso de UDTs en SQL Server no degrada el rendimiento. Proporciona los beneficios de garantizar la compatibilidad entre columnas y permite una recuperación más fácil de columnas del mismo tipo específico.