Les normes SQL92 et SQL99 définissent les constructions DDL . Toutes les bases de données ne le prennent pas en charge ou ne portent pas un nom différent (SQL Server a des types définis par l'utilisateur , par exemple).CREATE DOMAIN

Celles-ci permettent de définir un type de données contraint à utiliser dans leur base de données, pour simplifier et appliquer les règles relatives aux valeurs autorisées. Un tel type de données pourrait être utilisé dans les déclarations de colonnes, dans les entrées et sorties des procédures et fonctions stockées, etc.

J'aimerais savoir:

• Les gens utilisent-ils réellement des domaines dans leurs conceptions de base de données?
• Si oui, dans quelle mesure?
• Sont-ils utiles?
• Quels pièges avez-vous rencontrés?

J'essaie d'évaluer la viabilité de leur utilisation dans le développement futur de bases de données.

Comme d'habitude...

Ça dépend

Avez-vous une entité de domaine utilisée à plus d'un endroit dont la prise en charge native nécessiterait autrement des efforts considérables et / ou des contraintes et des comportements redondants ?

Si c'est le cas, retirez le domaine. Sinon, ne vous embêtez pas.

J'ai trouvé nécessaire de créer un type défini par l'utilisateur dans SQL Server exactement une fois, sur la base de l'heuristique ci-dessus. Je ne me souviens même plus de ce que c'était - mais cela a sauvé plus de travail qu'il n'en a causé.

En tant qu'utilisateur de SQL Server et C #, je n'ai pas utilisé de types définis par l'utilisateur dans la base de données, car je suis assez plus puissant côté application. Événement après les ORM comme LINQ to SQL et Entity Framework, mon utilisation des capacités du serveur a beaucoup diminué.

Par exemple, j'utilisais l'intégration CLR pour charger certaines fonctions de conversion DateTime vers SQL Server pour transférer les dates-heures grégoriennes dans d'autres formats, en fonction de la puissance de mondialisation de .NET. Mais maintenant, les choses sont différentes, et je ne fais plus ça. Je charge simplement les données et fais la transformation directement dans ma couche d'application.

Donc, après près de 4 ans de programmation et d'inspection de toutes les équipes auxquelles je peux penser, je n'ai trouvé aucun exemple d'utilisation de types définis par l'utilisateur. Je ne l'ai pas non plus vu en action dans de nombreux blogs .NET.

Bien que cela ne signifie pas que les gens n'utilisent pas le domaine de base de données , cela signifie sûrement qu'au moins l'utilisation du domaine de base de données n'est pas si courante.

Il y a déjà une réponse détaillée sur Stack Overflow. Je suis principalement d'accord avec cela, mais pas avec l'exemple donné, je cite:

"Par exemple, je définis un" GenderType "(char (1), non nullable, contenant" M "ou" F ") qui garantit que seules les données appropriées sont autorisées dans le champ Gender."

Personnellement, je me sens plus à l'aise pour définir le char(1)type et définir une contrainte sur la colonne. Lorsque la contrainte est violée, je sais exactement où chercher pour trouver ce que j'ai fait de mal. Il est également plus connu que les types définis par l'utilisateur, de sorte que la base de données qui n'utilise que des contraintes serait plus facile à comprendre pour un débutant.

Bien sûr, ce n'est qu'une opinion personnelle. D'autres diraient qu'unin ('M', 'F') contrainte n'est pas auto-documentée et peut être très obscure pour un nouveau développeur qui découvre la base de données.

OMI, utilisez des types définis par l'utilisateur pour les types plus compliqués et des contraintes pour quelque chose de basique. En outre, lorsque vous ne pouvez pas trouver facilement un nom explicite pour un type, il est possible qu'une contrainte convienne mieux.

Je n'ai pas utilisé cette fonctionnalité moi-même mais je suppose que vous devez vous assurer que:

1. Si votre base de données est utilisée par un seul système, il peut être judicieux de ne pas utiliser cette fonctionnalité et d'ajouter la logique de vérification dans votre couche métier ou son équivalent. Cela vous donnera plus de flexibilité dans la validation (par exemple en utilisant des expressions régulières) et permettra d'encapsuler toute la logique de validation en un seul endroit. Si votre base de données est partagée par plusieurs systèmes, vous pouvez utiliser à la place des déclencheurs bien adaptés à cette tâche.

2. Je ne sais pas si UDT vous permet de personnaliser les messages d'erreur renvoyés au client lorsqu'une erreur de validation est rencontrée.

3. Les UDT sont très utiles si la même règle de validation s'applique à plusieurs colonnes. À mon avis, je ne vois pas cela comme un cas très courant dans les applications commerciales avec une conception de base de données normalisée.

Vous pouvez être intéressé par la vérification de "Quel est l' intérêt des types définis par l'utilisateur [SQL Server]?" article de blog.

Lorsque vous dites "toutes les bases de données ne le prennent pas en charge", je pense qu'une meilleure façon de le dire est la suivante:

Chaque base de données principale prend en charge cela, car elle prend largement en charge les déclencheurs, les fonctions et d'autres fonctionnalités avancées.

Cela nous amène à la conclusion que cela fait partie du SQL avancé et a du sens à un moment donné.

Do people actually use domains in their database designs?

Le moins possible, en raison de la couverture étendue requise (compte tenu des opérateurs, des index, etc.)

If so to what extent?

Encore une fois, aussi limité que cela puisse être, si un type existant combiné à un peu de logique définie supplémentaire (par exemple des contrôles, etc.) peut faire l'affaire, pourquoi aller aussi loin?

How useful are they?

Beaucoup. Considérons une seconde un SGBD pas si bon que MySQL, que j'ai choisi pour cet exemple pour une raison: il manque un bon support pour le type inet (adresse IP).

Maintenant, vous voulez écrire une application qui se concentre principalement sur les données IP comme les plages et tout cela, et vous êtes coincé avec le type par défaut et ses fonctionnalités limitées, vous allez soit écrire des fonctions et des opérateurs supplémentaires (comme ceux pris en charge nativement dans postgreSQL pour exemple) ou écrivez des requêtes beaucoup plus complexes pour chaque fonctionnalité dont vous avez besoin.

Il s'agit d'un cas où vous justifierez facilement le temps passé à définir vos propres fonctions (inet >> inet dans PostgreSQL: plage contenue dans l'opérateur de plage).

À ce stade, vous avez déjà justifié l'extension de la prise en charge du type de données, il n'y a qu'une autre étape pour définir un nouveau type de données.

Revenons maintenant à PostgreSQL qui a un support de type vraiment sympa mais sans int. Non signé dont vous avez besoin, car vous êtes vraiment préoccupé par le stockage / les performances (qui sait ...), vous devrez l'ajouter ainsi que le opérateurs - bien que cela dérive principalement des opérateurs int existants.

What pitfalls have you encountered?

Je ne joue pas avec ça car jusqu'à présent, je n'ai pas eu de projet qui exigeait et justifiait le temps requis pour cela.

Le plus gros problème que je peux voir venir serait de réinventer la roue, d'introduire des bogues dans la couche "sûre" (db), un support de type incomplet que vous ne réaliserez que des mois plus tard lorsque votre CONCAT (cast * AS varchar) échoue parce que vous n'a pas défini de cast (newtype comme varchar), etc.

Il y a des réponses qui parlent de "peu commun" etc. Certainement celles-ci sont et devraient être rares (sinon cela signifie que le dbms manque de beaucoup de types importants), mais d'un autre côté, il faut se rappeler qu'un (bon) db est conforme ACID ( contrairement à une application) et que tout ce qui concerne la cohérence y est mieux conservé.

Il existe de nombreux cas où la logique métier est gérée dans la couche logicielle et cela peut être fait en SQL, où c'est plus sûr. Les développeurs d'applications ont tendance à se sentir plus à l'aise au sein de la couche application et évitent souvent de meilleures solutions implémentées dans SQL, cela ne doit pas être considéré comme une bonne pratique.

Les UDT peuvent être une bonne solution pour l'optimisation, un bon exemple est donné dans une autre réponse sur le type m / f en utilisant char (1). S'il s'agissait d'un UDT, ce pourrait être un booléen à la place (sauf si nous voulons offrir les troisième et quatrième options). Bien sûr, nous savons tous que ce n'est pas vraiment une optimisation en raison de la surcharge de la colonne, mais la possibilité est là.

Sur papier, les UDT sont un excellent concept. Ils vous permettent de vraiment normaliser votre base de données (par exemple lorsque vous avez deux colonnes qui dépendent l'une de l'autre), et également d'encapsuler toute logique liée à votre nouveau type.

En pratique, le prix que vous payez (aujourd'hui) est trop élevé. Évidemment, il y a les frais généraux de développement, mais en dehors de cela, vous perdez le support d'une variété d'ORM et d'outils de reporting, et vous augmentez considérablement la complexité globale de la solution. Il n'y a pas trop de développeurs qui connaissent intimement les UDT, et je n'ai jamais vu d'UDT gérés utilisés en dehors des exemples.

Un des meilleurs exemples d'un type qui est mieux fait en tant qu'UDT (s'il n'existait pas déjà) devrait être hierarchyid( lien MSDN ). Afin de rester efficace, il stocke sa valeur dans un format binaire (par opposition aux implémentations personnalisées varchar habituelles), ce qui serait difficile à maintenir sans les fonctions du type. La dizaine de méthodes fournies par le type sont également mieux fournies dans le cadre du type, par opposition aux fonctions externes. J'envisagerais d'utiliser l'UDT géré personnalisé dans des cas comme celui-ci - où il y a un gain significatif à réaliser en fournissant une implémentation efficace et soignée en tant que type distinct.

Une question / réponse plus pratique. Votre entreprise permet-elle de l'utiliser?

C'est votre entreprise qui travaille avec plusieurs marques DBSQL qui gèrent différents DDL?

Chaque marque de base de données peut offrir de bonnes fonctionnalités supplémentaires, comme les types définis par l'utilisateur, mais, si votre entreprise utilise plusieurs bases de données, vous pouvez rencontrer des problèmes avec les fonctionnalités non standard.

Si l'entreprise n'est que vous, ou si vous pouvez décider quelles bases de données et fonctionnalités allez-vous utiliser, vous pouvez utiliser DDL

J'ai travaillé avec plusieurs projets où un type défini par l'utilisateur pourrait être utile, mais je devrais m'en tenir à des fonctionnalités plus standard, car nous avons dû traiter plusieurs bases de données. (s).