usuario type tipos tipo tablas tabla por parametro definidos dato create sql sql-server user-defined-types

type - tipos de tablas en sql server



¿Qué tan geniales son los tipos de datos definidos por el usuario en SQL Server? (4)

El pro de los tipos definidos por el usuario se aborda bastante bien por Alex Papadimoulis. Los contras han sido bien establecidos aquí.

También me gustaría señalar que la función sp_bindrule ha quedado en desuso, como se señala en la publicación de Alex. No estoy seguro de cuándo fue desaprobado, pero lo es ahora. De hecho, las reglas están en desuso en su conjunto.

Si quisiera crear un tipo con una restricción, consideraría usar un tipo de tabla definida por el usuario con una restricción de verificación en la (s) columna (s) apropiada (s). Esto también me da una manera de construir un tipo de datos complejo.

¿Los tipos de datos definidos por el usuario en SQL Server son algo que un usuario de SQL intermedio debe saber y usar?

¿Cuáles son los pros y los contras de usar UDT?


No utilizo UDT basados ​​en código porque no creo que la complejidad adicional justifique las ventajas. Utilizo T-SQL UDT porque hay muy poca complejidad adicional por lo que las ventajas merecen el esfuerzo. (¡Gracias a Marc_s por señalar que mi publicación original estaba incompleta!)

Respecto a las UDT basadas en código

Piénselo de esta manera: si su proyecto tiene un componente de código administrado (su aplicación) y un componente de base de datos (SQL Server), ¿qué ventaja real obtiene al definir el código administrado en la base de datos? ¿En mi experiencia? Ninguna.

La implementación es más difícil porque tendrá que agregar conjuntos a su implementación de base de datos y modificar estos conjuntos, agregar archivos, etc. dentro de SQL Server. También deberá activar el CLR en SQL Server (no es un gran problema, pero nadie me ha demostrado que esto no tendrá una penalización de rendimiento / memoria). Al final, tendrá exactamente lo que habría tenido si simplemente hubiera diseñado esto en el código de su aplicación. Puede haber alguna mejora en el rendimiento, pero realmente me parece un caso de optimización prematura, especialmente porque no sé si el rendimiento general sufre debido a que el CLR está activado o desactivado.

Nota: Supongo que estaría usando el CLR de SQL Server para definir sus tipos. HLGEM habla sobre SQL Server 2000, pero no estoy familiarizado con el 2000 y pensé que solo tenía UDF y no UDT en archivos DLL definidos externamente (pero no me cite ... ¡Realmente no estoy familiarizado con eso!).

Respecto a T-SQL UDTs

Las UDT T_SQL se pueden definir solo en SQL (vaya a "Programabilidad | Tipos | Tipos de datos definidos por el usuario" en SQL Server Management Studio). Para los UDT estándar , de hecho, le recomendaría que los domine. Son bastante fáciles y pueden hacer que su DDL sea más autodocumentada y puede imponer restricciones de integridad. Por ejemplo, defino un "GenderType" (char (1), que no admite nulos, que contiene "M" o "F") que garantiza que solo se permiten los datos apropiados en el campo de Sexo.

Los UDT son bastante fáciles en general, pero este artículo brinda un buen ejemplo de cómo llevarlo al siguiente nivel al definir una Regla para restringir los datos permitidos en su UDT.

Cuando contesté esta pregunta originalmente, me fijé en la idea de los tipos complejos, definidos por código ( golpea la palma de la mano ). Así que ... gracias Marc.


Nunca usarlos es mi consejo. Estás en un mundo de dolor si alguna vez tienes que cambiar la definición. Tal vez esto haya mejorado desde SQL Server 2000 y alguien con más familiaridad con las versiones más recientes pueda decirle si ahora es seguro meterse en el agua, pero hasta que lo confirme y lo haya comprobado yo mismo con una prueba, no lo haría. No lo ponga en mi sistema de producción.

Echa un vistazo a esta pregunta para obtener más información: ¿Cómo cambiar el tipo base de un UDT en Sql Server 2005?


Realmente no puedo recomendar el uso de ninguna de las características específicas de la implementación de SQL que lo hacen más difícil cuando está creciendo fuera de mssql y está migrando a otro dbms. Para nuestro dwh dbs comenzamos en mssql, migramos a oracle y desde el año pasado nos graduamos a hp vertica.