Partager via

Conditions requises pour le type défini par l’utilisateur

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 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.

Conditions requises pour l’implémentation des UDT

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 la Microsoft.SqlServer.Server.SqlUserDefinedTypeAttribute. L’utilisation de la 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 un static public (Shared en Visual Basic) Null méthode. 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 un static public (ou Shared) Parse méthode qui prend en charge l’analyse et une méthode de 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 un Read et une méthode Write.

  • L’UDT doit implémenter System.Xml.Serialization.IXmlSerializable, ou tous les champs et propriétés publics doivent être de types xml sérialisables 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 devez être true pour comparer les données dans l’ordre d’octet. Si l’interface IComparable n’est pas implémentée et que SqlUserDefinedTypeAttribute.IsByteOrdered est 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 classes surchargés.

  • 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 dépasser 128 caractères et doivent être conformes aux règles d’affectation de noms SQL Server pour les identificateurs définis dans 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 parmi 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.

  • Les membres ne peuvent pas être surchargés, à l’exception du constructeur de classe. 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 static (ou Shared) 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 seule méthode, CompareTo. Ceci est utilisé côté client dans les situations dans lesquelles il est souhaitable de comparer ou commander avec précision les valeurs UDT.

Sérialisation native

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

bool, d’octets, sbyte, court, ushort, int, uint, long long, ulong , float , double, , , , , , , , ,

Les types valeur composés de champs de ces types sont de bons candidats pour Native format, tels que struct en C#, ou Structure tels qu’ils sont connus dans Visual Basic .NET. 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 Native. Si la définition UDT est plus complexe et contient des types de données non dans la liste précédente, vous devez spécifier le format de sérialisation UserDefined à la place.

Le format Native a 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.

  • La System.Runtime.InteropServices.StructLayoutAttribute doit être spécifiée comme 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 Native sérialisation, consultez la Point UDT dans Créer des types définis par l’utilisateur avec ADO.NET.

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 actions suivantes dans votre code :

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

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

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

Pour obtenir un exemple d’UDT défini avec UserDefined sérialisation, consultez l’UDT Monétaire dans Créer des types définis par l’utilisateur avec ADO.NET.

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 le 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.

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

Format

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

IsByteOrdered

Valeur Boolean 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 au format de sérialisation UserDefined. Pour un UDT avec 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 dans la plage de 1 à 8000, 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éfinir isbyteordered

Lorsque la propriété Microsoft.SqlServer.Server.SqlUserDefinedTypeAttribute.IsByteOrdered est définie sur true, vous êtes en mesure de garantir 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 a eu lieu dans le code managé. Les fonctionnalités suivantes sont également prises en charge lorsque IsByteOrdered est défini sur 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 sur les colonnes de ce type.

  • Possibilité d’utiliser des clauses Transact-SQL ORDER BY, GROUP BYet 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.

Les formats de Native et de sérialisation UserDefined prennent en charge les opérateurs de comparaison suivants lorsque IsByteOrdered est défini sur true:

  • Égal à (=)
  • Non égal à (!=)
  • Supérieur à (>)
  • Inférieur à (<)
  • Supérieur ou égal à (>=)
  • Inférieur ou égal à (<=)

Implémenter la possibilité de nullabilité

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 prennent en charge 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 Créer des types définis par l’utilisateur avec ADO.NET.

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 en tant que static (ou Shared 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 Créer des types définis par l’utilisateur avec ADO.NET.

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 en documents ou flux au format XML. Vous pouvez choisir d’implémenter 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.

Contenu connexe

  • Last updated on