¿Los tipos de datos definidos por el usuario en SQL Server son algo que un usuario de SQL intermedio debería conocer y usar?¿Qué tan geniales son los tipos de datos definidos por el usuario en SQL Server?
¿Cuáles son los pros y los contras del uso de UDT?
Nunca los use es mi consejo. Estás en un mundo de dolor si alguna vez tienes que cambiar la definición. Tal vez esto ha mejorado desde SQL Server 2000 y alguien con más familiaridad con las versiones más nuevas puede decirle si ahora es seguro meterse en el agua, pero hasta que haya confirmado esto y lo haya comprobado con una prueba, no lo haría. Ponlo en mi sistema de producción.
Salida esta pregunta para más detalles: How to change the base type of a UDT in Sql Server 2005?
que he usado ellos desde 2000 y nunca tuvieron ningún problema. He cambiado varios de ellos ... Los uso regularmente para los tipos que necesitan validación o restricciones personalizadas (artículos personalizados, etc.). Los recomiendo mucho para este uso, especialmente cuando se está construyendo un sistema para un marco. Cualquiera que use una manta 'no los use' es casi siempre wong, sin importar qué característica sea. – Dawesi
debo hacer UDT basados en código no uso, ya que no creo que la complejidad adicional garantiza las ventajas. I do use UDT T-SQL porque hay muy poca complejidad adicional, por lo que las ventajas valen la pena. (Nuestro agradecimiento a Marc_s para señalar que mi post original era incompleta!)
En cuanto a los UDT basadas en código
creo que 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 código administrado en la base de datos? ¿En mi experiencia? Ninguna.
La implementación es más difícil porque tendrá que agregar ensamblajes a su implementación de base de datos y modificar estos ensamblajes, agregar archivos, etc. dentro de SQL Server. También tendrá que encender 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ás exactamente lo que hubieras tenido si simplemente hubieras diseñado esto en el código de tu 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 de sufre debido a que el CLR está activado o desactivado.
Nota: supongo que utilizará el CLR de SQL Server para definir sus tipos. HLGEM habla de SQL Server 2000 pero no estoy familiarizado con 2000 y pensé que solo tenía UDF y no UDT en dlls definidos externamente (pero no me cité ... ¡Realmente no estoy familiarizado con esto!).
Con respecto a T-SQL UDT
T_SQL UDT se puede definir en SQL sola (vaya a "Programación | Tipos | definidos por el usuario Tipos de datos" en SQL Server Management Studio). Para los UDT estándar I sería de hecho recomendaría que los domines. Son bastante fáciles y pueden hacer que su DDL sea más autodocumentado y pueden imponer restricciones de integridad. Por ejemplo, defino un "Tipo de género" (char (1), no anulable, sosteniendo "M" o "F") que asegura que solo se permiten datos apropiados en el campo Género.
Los UDT son bastante fáciles en general, pero this article da un buen ejemplo de cómo llevarlo al siguiente nivel al definir una Regla para restringir los datos permitidos en su UDT.
Cuando respondí originalmente esta pregunta me fijé en la idea de los tipos complejos definidos por código (golpea la palma en la frente). Entonces ... gracias Marc.
UDT (tipo definido por el usuario) no significa necesariamente "código administrado". Puede definir un UDT basado en T-SQL directo y usarlo. CREAET TYPE ZipCode FROM varchar (10) NOT NULL; No digo que sea genial y recomendable, pero no es necesariamente código administrado .... –
El profesional de los tipos definidos por el usuario es addressed quite well 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 obsoleta, como señaló la publicación de Alex. No estoy seguro de cuándo fue obsoleto, pero ahora lo es. 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 definido por el usuario con una restricción de verificación en la (s) columna (s) apropiada (s). Esto también me da una forma de construir un tipo de datos complejo.
Mi uso principal de ellos es como Alex Descrito (mejores contraints) – Dawesi
Realmente no puedo recomendar el uso de cualquier característica específica de implementación sql que lo haga más difícil cuando esté saliendo de mssql y esté migrando a otro dbms. Para dwh dbs, comenzamos en mssql, migramos a Oracle y desde el año pasado nos graduamos a HP Vertica.
Personalmente, en el mundo .Net, SQL Server es el maullido del gato en mi opinión. Visual Studio tiene un SLEW de herramientas que se integran a SQL Server. Puede ejecutar consultas, crear tablas, etc. directamente desde el IDE VS2013. También puede crear un proyecto de base de datos SQL Server en VS2013 para administrar toda la base de datos y configurar Publishing para publicarlo en servidores de desarrollo/producción, lo cual es un sueño para una base de datos en la que trabajan varios desarrolladores, ya que permite verificar la base de datos controlar.
Creo que estar en C#, en Windows/Windows Server, y No usar SQL Server es una pérdida de productividad/rendimiento.
Como tal, creo que es una locura no aprovechar las características UDT y UDF. Son supremamente increíbles y me han permitido hacer algunas cosas geniales.
E.g. Tengo un servidor WebSocket que mantiene las conexiones de HTML 5 desde los clientes de WebSocket, y tengo funciones definidas por el usuario en SQL, de modo que mis actualizaciones/borrados/inserciones de tabla pueden notificar los cambios a los clientes conectados.
También tengo un UserDefinedType que gestiona automáticamente Grabbing Files de la base de datos.
E.g. tenemos una tabla de archivos binarios con un ID de archivo, nombre de archivo, etc. Luego tengo un UDT que puedo usar en otras tablas para hacer referencia a los archivos. El UDT tiene métodos para recuperar los archivos de la Tabla SQL y almacenarlos en caché.
E.g. si el archivo en caché del UDT (en el disco) está sincronizado con la versión en la fila de datos, entonces carga el archivo del caché; de lo contrario, realiza una operación sql para obtener el archivo y luego lo almacena en caché la próxima vez que se lo pida . El caché es configurable y consumirá X cantidad de espacio y mantendrá los últimos archivos accedidos en el caché. P.ej. si el caché está lleno, elimina los archivos en caché más antiguos para dejar espacio para los nuevos. Nuestro caché también está en una SSD.
Lo siento, piense que se está confundiendo entre los tipos definidos por el usuario y las funciones definidas por el usuario , así como entre SQL y OOP en general. Los tipos definidos por el usuario de SQL no tienen métodos y no pueden "administrar automáticamente" nada. Se crean cuando el motor de base de datos de SQL Server ejecuta la instrucción DDL CREATE TYPE, y pueden o no basarse en ensamblajes CLR (aunque creo que siempre se implementan como tipos CLR detrás de escena). – DaveBoltman
enfoque manual, pero me salvaron la vida útil: conexión de referencia: http://stackoverflow.com/questions/1383494/alter-user-defined-type-in-sql-server –