est la création de meilleures pratiques types de données définis par l'utilisateur db?

Question

est la création de types définis par l'utilisateur au lieu d'utiliser les meilleures pratiques types existants? Dans mes prévisualisations lieu de travail tous les types de base ont été prédéfinies, est-il la meilleure pratique? quels avantages et quels inconvénients qu'il a.
Merci beaucoup!

Answer 1

Dans MS SQL Server - l'idée est grande. Cependant, il y a une grande mais pour les: vous ne pouvez pas les changer une fois qu'ils sont en cours d'utilisation, car il n'y a pas de déclaration ALTER TYPE ..... Cela peut être un souci majeur.

Considérez ceci: vous avez une application de librairie qui a un type défini par l'utilisateur ISBN = VARCHAR (10) - fonctionne comme un charme. Maintenant, le Comité international a décidé de increate le champ ISBN à 13 caractères - malheureusement, il n'y a pas ALTER TYPE ISBNType..... donc votre seul choix est de laisser tomber essentiellement toutes les colonnes de ce type dans l'ensemble de votre base de données, puis recréer le type dans sa nouvelle forme, et recréer toutes ces colonnes à nouveau.

L'idée est grande et j'aimerais l'utiliser - mais dans son état actuel, il est à côté de inutilisable, à mon avis, ce qui est regrettable

.

Marc

Answer 2

Un peu en retard, mais .. mes 2 cts.

L'utilisateur types définis remplissent le rôle d'un domaine dans les modèles conceptuels et logiques, donc si vous souhaitez implémenter votre logique datamodel dans la base de données physique, l'utilisation de types définis par l'utilisateur seraient le plus proche approximation. Cela fournira des avantages tels que l'utilisation d'un modèle graphique qui peut être transféré à une mise en œuvre automatiquement, mieux que cela pourrait se faire sans utiliser UDT.

Utilisation de domaines permet de détecter les tentatives de stocker un code postal dans un champ et ont les SSN pris par la base de données au moment de l'exécution (ou même la compilation). Cela vous permettra de faire respecter les règles dans toute l'entreprise d'affaires où elles devraient être appliquées: au point où les données touche le stockage. Partout ailleurs est une courtoisie à l'utilisateur, mais c'est là qu'ils doivent absolument être appliquées pour vous assurer que Noone va autour d'eux.

En outre, UDT tel que défini dans la norme ANSI SQL: 1999 méthodes de encapsulent et peuvent être sous-typés. Cela signifie que certains changements dans les règles commerciales qui traitent des contraintes peuvent être modifiées dans la base de données, sans jamais avoir à toucher une mise en œuvre.

Mais ... comme UDT actuellement mis en œuvre laissent beaucoup à désirer. Je ne suis même pas sûr que SQL Server implémente le standard comme décrit, encore moins sûr Oracle. Et même s'ils le font, les inconvénients de l'utilisation UDT deviendra évident tout de suite que vous utilisez l'outillage BI, outillage ETL ou d'autres outils assez simples d'esprit: ils ne comprennent généralement pas UDT et même si elles le font, ils ne seront pas en mesure de les utiliser parce que la majorité se fondent sur les types de base (int, char et date / heure).

En ce qui concerne les outils de reporting, considérons un UDT qui a une combinaison de champs. Maintenant, comment un ETL-outil de base de données agnostique être en mesure de comprendre le type? Il devrait être en mesure de comprendre la structure afin de l'afficher ou l'utiliser pour les calculs. Et que pour chaque base de données pris en charge - une tâche difficile. Et puisque Noone utilise UDT, ils ne le feront pas. Il est un cercle vicieux, mais nous avons encore à vivre avec.

En dehors de cela, le soutien UDT dans la plupart des bases de données ne sont pas tout ce que ce soit chaud. Modification des types peut être assez difficile. Bien que la syntaxe doit être la même partout, leur administration est indéfini dans SQL: 1999 et donc différent partout. Essayez de changer le propriétaire d'un UDT dans le serveur SQL pour un exemple. Qui était autrefois assez difficile -. Pas sûr de SQL Server 2016, mais étant donné que les UDT ne ressemblent pas à une zone de mise au point, je ne suis pas attendre des améliorations majeures dans ce domaine

Enfin, si vous ajoutez le code vraiment complexe à UDT, vous courez dans le vieux problème que vous programmez dans un environnement qui a un manque de bonnes options de débogage. Cela ne nous aide pas non plus.

: si vous avez le contrôle total sur votre base de données et toutes les interactions passe par votre logiciel, UDT peut être extrêmement utile. Dans le cas contraire, ils peuvent être une énorme douleur au cou. Lequel est le cas dans votre scénario, est quelque chose que vous pouvez dire.

Answer 3

Comment refroidir sont les types de données définis par l'utilisateur dans MS SQL Server?

Personnellement, je ne les utilise pas, mais je les ai vu. Un problème est que le code client reconnaît le type de base uniquement, IIRC, pour MS SQL Server au moins. Et portabilité / comportements à travers les versions.