Como de costumbre ...

Depende

¿Tiene una entidad de dominio utilizada en más de un lugar que dar soporte de forma nativa requeriría un esfuerzo considerable o restricciones y comportamientos redundantes ?

Si es así, el dominio de distancia. Si no, no te molestes.

He encontrado que es necesario crear un tipo definido por el usuario en SQL Server exactamente una vez, según la heurística anterior. Ni siquiera recuerdo qué era más, pero ahorró más trabajo del que causó.

Como usuario de SQL Server y C #, no he usado tipos definidos por el usuario en la base de datos, ya que soy bastante más poderoso en el lado de las aplicaciones. Evento después de ORM como LINQ to SQL y Entity Framework, mi uso de las capacidades del servidor se ha reducido mucho.

Por ejemplo, estaba usando la integración CLR para cargar algunas funciones de conversión de DateTime a SQL Server para transferir las fechas y los horarios gregorianos a otros formatos, según el poder de globalización de .NET. Pero ahora, las cosas son diferentes, y ya no hago eso. Simplemente cargo los datos y hago la transformación, justo en la capa de mi aplicación.

Entonces, después de casi 4 años de programar e inspeccionar todos los equipos en los que puedo pensar, no he encontrado ninguna muestra de cómo usar los tipos definidos por el usuario. Tampoco lo he visto en acción en muchos blogs .NET.

Si bien esto no significa que las personas no utilicen Dominio de base de datos , seguramente significa que al menos el uso de Dominio de base de datos no es tan común.

Ya hay un respuesta detallada en Desbordamiento de pila. En general estoy de acuerdo con eso, pero no con el ejemplo dado, cito:

  

"Por ejemplo, defino un" GenderType "(char (1), no acepta nulos, con" M "o" F ") que asegure que solo se permita la información apropiada en el campo Gender."

Personalmente, me siento más cómodo configurando el tipo char(1) y definiendo una restricción en la columna. Cuando se viola la restricción, sé exactamente dónde buscar para encontrar lo que hice mal. También es más conocido que los tipos definidos por el usuario, por lo que la base de datos que utiliza solo restricciones sería más fácil de entender para un principiante.

Por supuesto, solo es una opinión personal. Otras personas dirían que una restricción in ('M', 'F') no se auto-documenta y puede ser muy oscura para un desarrollador nuevo que descubre la base de datos.

OMI, use tipos definidos por el usuario para tipos más complicados y restricciones para algo básico. Además, cuando no puede encontrar fácilmente un nombre explícito para un tipo, existe la posibilidad de que una restricción se ajuste mejor.

No he usado esta función, pero creo que debes asegurarte de que:

1. Si su base de datos es utilizada por un solo sistema, puede tener sentido no usar esta función y agregar la lógica de verificación en su capa empresarial o su equivalente. Eso le dará más flexibilidad en la validación (por ejemplo, en el uso de expresiones regulares) y le permitirá encapsular toda la lógica de validación en un solo lugar. Si varios sistemas comparten su base de datos, en su lugar puede usar desencadenantes que sean adecuados para esta tarea.

2. No estoy seguro de si UDT le permite personalizar los mensajes de error devueltos al cliente cuando se encuentra un error de validación.

3. Los UDT son muy útiles si la misma regla de validación se aplica a varias columnas. En mi opinión, no veo esto como un caso muy común en una aplicación empresarial con un diseño de base de datos normalizado.

Es posible que le interese consultar "¿Cuál es el punto del usuario de [SQL Server]? ¿Tipos definidos? " artículo de blog.

Cuando dices "no todas las bases de datos admiten esto", creo que una mejor manera de ponerlo es la siguiente:

Todas las bases de datos principales lo admiten, ya que admiten extensamente activadores, funciones y otras funciones avanzadas.

Esto nos lleva a la conclusión de que esto es parte de SQL avanzado y tiene sentido en algún momento.

Do people actually use domains in their database designs?

Lo menos posible, debido a la extensa cobertura requerida (considerando operadores, índices, etc.)

If so to what extent?

Nuevamente, tan limitado como pueda ser, si un tipo existente combinado con un poco de lógica definida adicional (es decir, verificaciones, etc.) puede hacer el truco, ¿por qué ir tan lejos?

How useful are they?

Mucho. Consideremos por un segundo un DBMS no tan bueno como MySQL, que escogí para este ejemplo por una razón: carece de un buen soporte para el tipo inet (dirección IP).

Ahora desea escribir una aplicación que se centre principalmente en datos de IP como rangos y todo eso, y está atascado con el tipo predeterminado y su funcionalidad limitada, o escribirá funciones y operadores adicionales (como los admitidos de forma nativa en postgreSQL por ejemplo) o escriba consultas mucho más complejas para cada funcionalidad que necesite.

Este es un caso en el que justificará fácilmente el tiempo dedicado a definir sus propias funciones (inet > > inet en PostgreSQL: rango contenido en el operador de rango).

En ese momento, ya ha justificado la extensión de la compatibilidad con el tipo de datos, solo hay otro paso para definir un nuevo tipo de datos.

Ahora, de vuelta a PostgreSQL, que tiene un soporte de tipo realmente agradable pero no tiene int sin firmar. Lo que necesita, porque está realmente preocupado por el almacenamiento / rendimiento (quién sabe ...), así que deberá agregarlo como así como los operadores, aunque, por supuesto, esto se debe principalmente a los operadores int existentes.

What pitfalls have you encountered?

No he jugado con eso porque hasta ahora no he tenido un proyecto que requiriera y justificara el tiempo requerido para esto.

Los problemas más grandes que puedo ver son reinventar la rueda, introducir errores en la capa "segura" (db), soporte de tipo incompleto que solo se dará cuenta meses después cuando su CONCAT (cast * AS varchar) falla porque no definió una conversión (newtype como varchar), etc.

Hay respuestas que hablan de "poco común", etc. Definitivamente, estas son y deberían ser poco comunes (de lo contrario, significa que la dbms carece de muchos tipos importantes), pero por otro lado, uno debe recordar que una (buena) db es Compatible con ACID (a diferencia de una aplicación) y que todo lo relacionado con la consistencia se mantiene mejor allí.

Hay muchos casos en los que la lógica de negocios se maneja en la capa de software y se puede hacer en SQL, donde es más seguro. Los desarrolladores de aplicaciones tienden a sentirse más cómodos dentro de la capa de aplicación y, a menudo, evitan las mejores soluciones implementadas en SQL, esto no debe considerarse como una buena práctica.

Los UDT pueden ser una buena solución para la optimización, se da un buen ejemplo en otra respuesta sobre el tipo m / f usando char (1). Si hubiera sido un UDT, podría ser un booleano (a menos que queramos ofrecer las opciones tercera y cuarta). Por supuesto, todos sabemos que esto no es realmente una optimización debido a la sobrecarga de la columna, pero existe la posibilidad.

En el papel, los UDT son un gran concepto. Le permiten normalizar realmente su base de datos (por ejemplo, cuando tiene dos columnas que dependen una de la otra) y también encapsular cualquier lógica relacionada con su nuevo tipo.

En la práctica, el precio que paga (hoy) es demasiado alto. Obviamente, existe una sobrecarga de desarrollo, pero aparte de eso, pierde el soporte de una variedad de ORM y herramientas de informes, y aumenta bastante la complejidad general de la solución. No hay demasiados desarrolladores que estén familiarizados con los UDT, y nunca he visto UDT administrados que se usen fuera de los ejemplos.

Uno de los mejores ejemplos de un tipo que se realiza mejor como un UDT (si no existiera) tendría que ser hierarchyid ( MSDN link ). Para seguir siendo eficiente, almacena su valor en un formato binario (a diferencia de las implementaciones personalizadas varchar habituales), lo que sería complicado de mantener sin las funciones del tipo. Los 10 o más métodos que proporciona el tipo también se proporcionan mejor como parte del tipo, en lugar de funciones externas. Consideraría el uso de UDT administrado personalizado en casos como este, donde se puede obtener una ventaja significativa al proporcionar una implementación eficiente y ordenada como un tipo separado.

Una pregunta / respuesta más práctica. ¿Su empresa permite utilizarlo?

Es su empresa trabajando con varios D.B. S.Q.L. ¿Marcas que manejan diferentes DDL (s)?

Cada marca de base de datos puede ofrecer buenas características adicionales, como los tipos definidos por el usuario, pero, si su empresa utiliza varios D.B., puede tener problemas con las características no estándar.

Si la compañía es solo usted, o puede decidir qué Bases de datos & Si va a utilizar las funciones, entonces puede usar D.D.L.

He trabajado con varios proyectos en los que un Tipo Definido por el Usuario podría ser útil, pero debería atenerme a más características estándar, ya que tuvimos que lidiar con varios DB. (s).