Partager via

Création de types définis par l’utilisateur - Exigences

  • Article

S’applique à : SQL Server

Vous devez prendre plusieurs décisions de conception importantes lors de la création d’un type défini par l’utilisateur (UDT) à installer dans Microsoft SQL Server. Pour la plupart des types définis par l'utilisateur, il est recommandé de créer un type défini par l'utilisateur sous forme de structure mais il est également possible de le créer sous forme de classe. La définition UDT doit être conforme aux spécifications de création d’UDT afin qu’elle soit inscrite auprès de SQL Server.

Configuration requise pour l'implémentation des types définis par l'utilisateur

Pour s’exécuter dans SQL Server, votre UDT doit implémenter les exigences suivantes dans la définition UDT :

L’UDT doit spécifier microsoft.SqlServer.Server.SqlUserDefinedTypeAttribute. L’utilisation de System.SerializableAttribute est facultative, mais recommandée.

  • L’UDT doit implémenter l’interface System.Data.SqlTypes.INullable dans la classe ou la structure en créant une méthode Null statique publique (partagée dans Microsoft Visual Basic). SQL Server prend en compte la valeur null par défaut. Ceci est nécessaire pour que le code exécuté dans l'UDT puisse être en mesure de reconnaître une valeur NULL.

  • L’UDT doit contenir une méthode d’analyse statique publique (ou partagée) qui prend en charge l’analyse et une méthode ToString publique pour la conversion en une représentation sous forme de chaîne de l’objet.

  • Un UDT avec un format de sérialisation défini par l’utilisateur doit implémenter l’interface System.Data.IBinarySerialize et fournir une méthode Read et Write .

  • L’UDT doit implémenter System.Xml.Serialization.IXmlSerializable, ou tous les champs et propriétés publics doivent être de types sérialisables XML ou décorés avec l’attribut XmlIgnore si la substitution de la sérialisation standard est requise.

  • Chaque objet UDT doit être soumis à une seule sérialisation. La validation échoue si les routines de sérialisation ou désérialisation reconnaissent plusieurs représentations d'un objet en particulier.

  • SqlUserDefinedTypeAttribute.IsByteOrdered doit être true pour comparer les données dans l’ordre d’octet. Si l’interface IComparable n’est pas implémentée et SqlUserDefinedTypeAttribute.IsByteOrdered a la valeur false, les comparaisons d’ordre d’octets échouent.

  • Un UDT défini dans une classe doit disposer d'un constructeur public qui n'accepte aucun argument. Vous pouvez éventuellement créer des constructeurs de classe surchargés supplémentaires.

  • L'UDT doit dévoiler les éléments de données sous forme de champs publics ou de procédures de propriété.

  • Les noms publics ne peuvent pas comporter plus de 128 caractères et doivent être conformes aux règles d’affectation de noms SQL Server pour les identificateurs définis dans les identificateurs de base de données.

  • sql_variant colonnes ne peuvent pas contenir d’instances d’un UDT.

  • Les membres hérités ne sont pas accessibles à partir de Transact-SQL, car le système de type SQL Server n’est pas conscient de la hiérarchie d’héritage entre les UDT. Toutefois, vous pouvez recourir à la fonction d'héritage au moment de structurer vos classes et pouvez appeler ces méthodes dans l'implémentation du code managé du type.

  • Hormis le constructeur de classe, les membres ne peuvent pas être surchargés. Si vous créez une méthode surchargée, aucune erreur n’est générée lorsque vous inscrivez l’assembly ou créez le type dans SQL Server. La détection de la méthode surchargée a lieu au moment de l'exécution et non lors de la création du type. Les méthodes surchargées peuvent exister dans la classe tant qu'elles ne sont jamais appelées. Une erreur est générée dès que vous appelez la méthode surchargée.

  • Tous les membres statiques (ou partagés) doivent être déclarés en tant que constantes ou en lecture seule. Les membres statiques ne peuvent pas être mutables.

  • Si le champ SqlUserDefinedTypeAttribute.MaxByteSize est défini sur -1, l’UDT sérialisé peut être aussi volumineux que la limite de taille de l’objet volumineux (actuellement 2 Go). La taille de l’UDT ne peut pas dépasser la valeur spécifiée dans le champ MaxByteSized .

Remarque

Bien qu’il ne soit pas utilisé par le serveur pour effectuer des comparaisons, vous pouvez éventuellement implémenter l’interface System.IComparable , qui expose une méthode unique, CompareTo. Elle intervient côté client dans des situations où il est préférable de comparer ou de classer avec précision des valeurs de type défini par l'utilisateur (UDT).

Sérialisation native

Le choix du bon attribut de sérialisation pour votre UDT dépend du type d'UDT que vous essayez de créer. Le format de sérialisation native utilise une structure très simple qui permet à SQL Server de stocker une représentation native efficace de l’UDT sur le disque. Le format natif est recommandé si l’UDT est simple et contient uniquement des champs des types suivants :

bool, byte, sbyte, short, ushort, int, uint, long, ulong, float, double, SqlByte, SqlInt16, SqlInt32, SqlInt64, SqlDateTime, SqlSingle, SqlDouble, SqlMoney, SqlBoolean

Les types valeur qui sont composés de champs des types ci-dessus sont de bons candidats au format natif , tels que les structs dans Visual C#, (ou structures telles qu’elles sont connues en Visual Basic). Par exemple, un UDT spécifié avec le format de sérialisation native peut contenir un champ d’un autre UDT qui a également été spécifié avec le format natif . Si la définition UDT est plus complexe et contient des types de données non dans la liste ci-dessus, vous devez spécifier le format de sérialisation UserDefined à la place.

Le format natif présente les exigences suivantes :

  • Le type ne doit pas spécifier de valeur pour Microsoft.SqlServer.Server.SqlUserDefinedTypeAttribute.MaxByteSize.

  • Tous les champs doivent être sérialisables.

  • System.Runtime.InteropServices.StructLayoutAttribute doit être spécifié en tant que StructLayout.LayoutKindSequential si l’UDT est défini dans une classe et non dans une structure. Cet attribut contrôle la disposition physique des champs de données et est utilisé pour contraindre les membres à se placer dans l'ordre dans lequel ils apparaissent. SQL Server utilise cet attribut pour déterminer l’ordre des champs pour les UDT avec plusieurs valeurs.

Pour obtenir un exemple d’UDT défini avec sérialisation native , consultez l’UDT point dans le codage de types définis par l’utilisateur.

Sérialisation UserDefined

Le paramètre de format UserDefined pour l’attribut Microsoft.SqlServer.Server.SqlUserDefinedTypeAttribute donne au développeur un contrôle total sur le format binaire. Lorsque vous spécifiez la propriété d’attribut Format en tant que UserDefined, vous devez effectuer les opérations suivantes dans votre code :

  • Spécifiez la propriété d’attribut IsByteOrdered facultative. La valeur par défaut est false (Faux).

  • Spécifiez la propriété MaxByteSize de Microsoft.SqlServer.Server.SqlUserDefinedTypeAttribute.

  • Écrivez du code pour implémenter des méthodes de lecture et d’écriture pour l’UDT en implémentant l’interface System.Data.Sql.IBinarySerialize.

Pour obtenir un exemple d’UDT défini avec la sérialisation UserDefined , consultez l’UDT Monétaire dans le codage de types définis par l’utilisateur.

Remarque

Les champs UDT doivent utiliser la sérialisation native ou être persistants pour pouvoir être indexés.

Attributs de sérialisation

Les attributs déterminent la façon dont la sérialisation est utilisée pour construire la représentation de stockage des types définis par l'utilisateur et pour transmettre des types définis par l'utilisateur par valeur au client. Vous devez spécifier microsoft.SqlServer.Server.SqlUserDefinedTypeAttribute lors de la création de l’UDT. L’attribut Microsoft.SqlServer.Server.SqlUserDefinedTypeAttribute indique que la classe est un UDT et spécifie le stockage de l’UDT. Vous pouvez éventuellement spécifier l’attribut Serializable , bien que SQL Server ne le nécessite pas.

Microsoft.SqlServer.Server.SqlUserDefinedTypeAttribute a les propriétés suivantes.

Format
Spécifie le format de sérialisation, qui peut être natif ou UserDefined, en fonction des types de données de l’UDT.

IsByteOrdered
Valeur booléenne qui détermine la façon dont SQL Server effectue des comparaisons binaires sur l’UDT.

IsFixedLength
Indique si toutes les instances de cet UDT ont la même longueur.

MaxByteSize
Taille maximale de l'instance, en octets. Vous devez spécifier MaxByteSize avec le format de sérialisation UserDefined . Pour un UDT avec la sérialisation définie par l’utilisateur spécifiée, MaxByteSize fait référence à la taille totale de l’UDT dans sa forme sérialisée telle que définie par l’utilisateur. La valeur de MaxByteSize doit être comprise entre 1 et 8 000, ou définie sur -1 pour indiquer que l’UDT est supérieur à 8 000 octets (la taille totale ne peut pas dépasser la taille maximale du métier). Considérez un UDT avec une propriété d’une chaîne de 10 caractères (System.Char). Lorsque l'UDT est sérialisé à l'aide de BinaryWriter, la taille totale de la chaîne sérialisée est de 22 octets : 2 octets par caractère Unicode UTF-16, multipliés par le nombre maximal de caractères, plus 2 octets de contrôle de la charge mémoire générée par la sérialisation d'un flux binaire. Par conséquent, lors de la détermination de la valeur de MaxByteSize, la taille totale de l’UDT sérialisée doit être prise en compte : la taille des données sérialisées sous forme binaire, ainsi que la surcharge engendrée par la sérialisation.

ValidationMethodName
Nom de la méthode utilisée pour valider des instances du type défini par l'utilisateur.

Définition de la propriété IsByteOrdered

Lorsque la propriété Microsoft.SqlServer.Server.SqlUserDefinedTypeAttribute.IsByteOrdered a la valeur true, vous garantissez que les données binaires sérialisées peuvent être utilisées pour l’ordre sémantique des informations. Par conséquent, chaque instance d'un objet UDT ordonné par octet peut avoir une seule représentation sérialisée. Lorsqu’une opération de comparaison est effectuée dans SQL Server sur les octets sérialisés, ses résultats doivent être identiques si la même opération de comparaison avait eu lieu dans le code managé. Les fonctionnalités suivantes sont également prises en charge lorsque IsByteOrdered a la valeur true :

  • Possibilité de créer des index dans les colonnes de ce type.

  • Possibilité de créer des clés primaires et étrangères ainsi que des contraintes CHECK et UNIQUE dans les colonnes de ce type.

  • Possibilité d’utiliser des clauses Transact-SQL ORDER BY, GROUP BY et PARTITION BY. Dans ces cas, la représentation binaire du type est utilisée pour déterminer l'ordre.

  • Possibilité d’utiliser des opérateurs de comparaison dans des instructions Transact-SQL.

  • Possibilité de rendre persistantes des colonnes calculées de ce type.

Notez que les formats de sérialisation Native et UserDefined prennent en charge les opérateurs de comparaison suivants lorsque IsByteOrdered a la valeur true :

  • Égal(e) à (=)

  • Différent de (!=)

  • Supérieur à (>)

  • Inférieur à (<)

  • Supérieur ou égal à (>=)

  • Inférieur ou égal à (<=)

Implémentation de la possibilité de valeur NULL

En plus de spécifier correctement les attributs de vos assemblys, votre classe doit également prendre en charge la possibilité de valeur NULL. Les UDT chargés dans SQL Server sont conscients de la valeur Null, mais pour que l’UDT reconnaisse une valeur Null, la classe doit implémenter l’interface INullable . Pour plus d’informations et un exemple d’implémentation de la nullabilité dans un UDT, consultez Codage de types définis par l’utilisateur.

Conversions de chaînes

Pour prendre en charge la conversion de chaîne vers et à partir de l’UDT, vous devez fournir une méthode Parse et une méthode ToString dans votre classe. La méthode Parse permet de convertir une chaîne en un UDT. Elle doit être déclarée statique (ou partagée en Visual Basic) et prendre un paramètre de type System.Data.SqlTypes.SqlString. Pour plus d’informations et un exemple d’implémentation des méthodes Parse et ToString, consultez Codage des types définis par l’utilisateur.

Sérialisation XML

Les UDT doivent prendre en charge la conversion vers et à partir du type de données xml en respectant le contrat pour la sérialisation XML. L’espace de noms System.Xml.Serialization contient des classes utilisées pour sérialiser des objets dans des documents ou des flux au format XML. Vous pouvez choisir d’implémenter la sérialisation xml à l’aide de l’interface IXmlSerializable , qui fournit une mise en forme personnalisée pour la sérialisation ET la désérialisation XML.

En plus d’effectuer des conversions explicites de l’UDT en xml, la sérialisation XML vous permet de :

  • Utilisez Xquery sur les valeurs des instances UDT après la conversion vers le type de données xml .

  • Utilisez des UDT dans des requêtes paramétrables et des méthodes web avec des services web XML natifs dans SQL Server.

  • Utiliser des UDT pour recevoir un chargement en masse de données XML.

  • Sérialiser des datasets contenant des tables avec des colonnes UDT.

Les UDT ne sont pas sérialisés dans les requêtes FOR XML. Pour exécuter une requête FOR XML qui affiche la sérialisation XML des UDT, convertissez explicitement chaque colonne UDT en type de données xml dans l’instruction SELECT. Vous pouvez également convertir explicitement les colonnes en varbinary, varchar ou nvarchar.

Voir aussi

Création d’un type défini par l’utilisateur