es la creación de tipos de datos definidos por el usuario db mejores prácticas?

Question

es la creación de tipos definidos por el usuario en lugar de utilizar los tipos existentes las mejores prácticas? En mis vistas previas lugar de trabajo todos los tipos básicos eran predefinido, es que las mejores prácticas? ¿Qué ventajas y qué desventajas tiene
. ¡Muchas gracias!

Answer 1

En MS SQL Server - la idea es grande. Sin embargo, hay una gran y a ellos: no se puede cambiar una vez que estén en uso, ya que no hay ninguna declaración ALTER TYPE ..... Esto puede ser una molestia importante.

Considere esto: usted tiene una aplicación de librería que tiene un tipo definido por el usuario ISBN = VARCHAR (10) - funciona como un encanto. Ahora bien, el Comité Internacional decidió increate el campo ISBN a 13 caracteres - por desgracia, no hay ALTER TYPE ISBNType..... por lo que su única opción es dejar caer básicamente todas las columnas de ese tipo en la totalidad de su base de datos, a continuación, volver a crear el tipo en su nueva forma, y volver a crear todas esas columnas de nuevo.

La idea es genial y me gustaría utilizarlo - pero en su estado actual, que está al lado inservible, en mi opinión, lo cual es lamentable

.

Marc

Answer 2

Un poco tarde, pero .. mis 2 cts.

El usuario tipos definidos cumplen el papel de un dominio en los modelos conceptuales y lógicos, por lo que si se desea implementar el modelo de datos lógico en la base de datos física, el uso de tipos definidos de usuario sería la aproximación más cercana. Esto proporcionará beneficios tales como el uso de un modelo gráfico que puede ser transferida a una implementación automática, mejor de lo que se podría hacer sin necesidad de utilizar UDT.

El uso de dominios hace que sea posible detectar intentos para almacenar un código postal en un campo SSN y les han caído en la base de datos en tiempo de ejecución (o incluso en tiempo de compilación). Esto le permitirá cumplir las reglas de negocio en toda la empresa en la que se deben hacer cumplir: en el punto donde los datos golpea el almacenamiento. En cualquier otro lugar es una cortesía para el usuario, pero esto es donde todo tiene que ser forzada para asegurarse de que nadie va alrededor de ellos.

Además, UDT como se define en ANSI SQL: 1999 métodos encapsular, y se pueden subtipificados. Eso significa que ciertos cambios en las reglas de negocio que tienen que ver con las limitaciones se pueden cambiar en la base de datos, sin tener que tocar una implementación.

Sin embargo ... UDT tal como se aplica actualmente dejan mucho que desear. Ni siquiera estoy seguro de SQL Server implementa el estándar como se describe, aún menos seguro acerca de Oracle. E incluso si lo hacen, las desventajas del uso de los UDT se hará evidente de inmediato, ya que utiliza las herramientas de BI, herramientas ETL o de otras herramientas más simplista: por lo general no entienden UDT e incluso si lo hacen, no van a ser capaz de utilizarlas porque la mayoría basarse en los tipos básicos (int, carbón de leña y fecha / hora).

En cuanto a herramientas de información, vamos a considerar un UDT que tiene una combinación de campos. Ahora, ¿cómo sería un ETL-herramienta de base de datos independiente del poder entender el tipo? Tendría que ser capaz de entender la estructura con el fin de visualizarlo, o utilizarlo para los cálculos. Y que por cada base de datos compatible - una tarea difícil. Y puesto que nadie utiliza UDT, no van a hacer esto. Es un círculo vicioso, pero todavía tenemos que vivir con ello.

Aparte de eso, el apoyo UDT en la mayoría de las bases de datos no es tan caliente o. Cambio de tipos puede ser muy duro. Si bien la sintaxis debe ser el mismo en todas partes, su administración no está definido en SQL: 1999 y por lo tanto diferentes en todas partes. Intente cambiar el propietario de un UDT en el servidor SQL para un ejemplo. Eso solía ser bastante difícil -. No está seguro acerca de SQL Server 2016, pero dado que los UDT no se ven como un área de enfoque, no espero grandes mejoras en esa área

Por último, si se agrega código muy complejo para los UDT, se encuentra con el viejo problema que se está programando en un ambiente que tiene una falta de buenas opciones de depuración. Eso no ayuda tampoco.

Por lo tanto: si usted tiene un control total sobre su base de datos y toda la interacción pasa a través de su software, UDT pueden ser extremadamente útiles. Si no, pueden ser un gran dolor de cuello. ¿Cuál es el caso en su escenario, es algo que sólo se puede decir.

Answer 3

¿Cómo fresca son definidos por el usuario Tipos de datos en MS SQL Server?

En lo personal, yo no los uso, pero los he visto. Un problema es que el código de cliente reconoce el tipo de base única, IIRC, para MS SQL Server al menos. Y la portabilidad / comportamientos a través de versiones.