Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier les répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer de répertoire.
S’applique à :SQL Server
Azure SQL Database
Azure SQL Managed Instance
Base de données SQL dans Microsoft Fabric
Le type de données hierarchyid est un type de données système de longueur variable. Utilisez hierarchyid pour représenter une position dans une hiérarchie. Une colonne de type hierarchyid ne représente pas automatiquement une arborescence. Il incombe à l’application de générer et d’affecter des valeurs hierarchyid de telle sorte que la relation souhaitée entre les lignes soit reflétée dans les valeurs.
Une valeur du type de données hierarchyid représente une position dans une hiérarchie d'arborescence. Les valeurs de hierarchyid ont les propriétés suivantes :
Extrêmement compact : le nombre moyen de bits requis pour représenter un nœud dans une arborescence avec n nœuds dépend du ventilateur moyen (nombre moyen d’enfants d’un nœud). Pour les petits ventilateurs (0-7), la taille est d’environ 6 * logA n bits, où A est le ventilateur moyen. Un nœud dans une hiérarchie organisationnelle de 100 000 personnes avec une fanout moyenne de six niveaux prend environ 38 bits. Ce chiffre est arrondi à 40 bits, ou 5 octets, pour le stockage.
La comparaison est dans un premier ordre de profondeur : étant donné deux valeurs
aetb,a<bsignifie qu’une valeur est antérieure à b dans un travers de profondeur premier de l’arbre. Les index sur les types de données hierarchyid sont dans l’ordre à profondeur prioritaire, et les nœuds proches les uns des autres dans un parcours à profondeur prioritaire sont stockés les uns à côté des autres. Par exemple, les enfants d'un enregistrement sont stockés à côté de cet enregistrement. Pour plus d’informations, consultez Données hiérarchiques (SQL Server).Prise en charge des insertions et suppressions arbitraires : à l’aide de la méthode GetDescendant , il est toujours possible de générer un frère à droite de n’importe quel nœud donné, à gauche d’un nœud donné, ou entre deux frères. La propriété de comparaison est maintenue lorsqu'un nombre arbitraire de nœuds est inséré ou supprimé dans la hiérarchie. La plupart des insertions et suppressions préservent la propriété de compacité. Toutefois, les insertions entre deux nœuds produisent des valeurs hierarchyid avec une représentation légèrement moins compacte.
L’encodage est limité à 892 octets : Par conséquent, les nœuds qui ont trop de niveaux dans leur représentation pour s’adapter à 892 octets ne peuvent pas être représentés par le type hierarchyid .
Le type hierarchyid est disponible pour les clients CLR (Common Language Runtime) comme SqlHierarchyId type de données.
Remarks
Le type hierarchyid encode logiquement les informations sur un nœud unique dans une arborescence hiérarchique en encodant le chemin de la racine de l’arborescence au nœud. Un tel chemin d'accès est représenté logiquement comme une séquence d'étiquettes de nœud de tous les enfants visités après la racine. Une barre oblique démarre la représentation et un chemin d'accès qui visite uniquement la racine est représenté par une barre oblique unique. Pour les niveaux sous la racine, chaque étiquette est encodée comme une séquence d'entiers séparés par des points.
La comparaison entre les enfants est effectuée en comparant les séquences d'entiers séparés par des points dans le classement du dictionnaire. Chaque niveau est suivi d'une barre oblique. Par conséquent, une barre oblique sépare les parents de leurs enfants. Par exemple, les éléments suivants sont des chemins de hierarchyid valides de longueurs 1, 2, 2, 3, sur 3 niveaux respectivement :
//1//0.3.-7//1/3//0.1/0.2/
Les nœuds peuvent être insérés à tout emplacement. Nœuds insérés après /1/2/ mais avant /1/3/ peuvent être représentés en tant que /1/2.5/. Les nœuds insérés avant 0 d’avoir la représentation logique sous la forme d’un nombre négatif. Par exemple, un nœud qui vient avant /1/1/ peut être représenté en tant que /1/-1/. Les nœuds ne peuvent pas avoir de zéros non significatifs. Par exemple, /1/1.1/ est valide, mais /1/1.01/ n’est pas valide. Pour éviter des erreurs, insérez des nœuds à l’aide de la méthode GetDescendant.
Conversion de types de données
Le type de données hierarchyid peut être converti en d’autres types de données comme suit :
Utilisez la méthode ToString pour convertir la valeur hierarchyid en représentation logique en tant que type de données nvarchar(4000).
Utilisez lecture (moteur de base de données) à l’aide de CSharp et d’écriture pour convertir hierarchyid en varbinary.
Pour transmettre des paramètres hierarchyid via SOAP, commencez par les convertir en chaînes.
Mettre à niveau les bases de données
Lorsqu’une base de données est mise à niveau vers une version plus récente de SQL Server, le nouvel assembly et le type de données hierarchyid sont installés automatiquement. Les règles du Conseiller de mise à niveau détectent tout type d’utilisateur ou assembly avec des noms en conflit. L’conseiller de mise à niveau conseille de renommer un assembly en conflit et de renommer un type en conflit ou d’utiliser des noms en deux parties dans le code pour faire référence à ce type d’utilisateur préexistant.
Si une mise à niveau de base de données détecte un assembly utilisateur avec un nom en conflit, il renomme automatiquement cet assembly et place la base de données en mode suspect.
Si un type d'utilisateur avec un nom en conflit existe pendant la mise à niveau, aucune étape spéciale n'est suivie. Après la mise à niveau, l’ancien type d’utilisateur et le nouveau type de système existent. Le type d’utilisateur est disponible uniquement par le biais de noms en deux parties.
Utiliser des colonnes hierarchyid dans des tables répliquées
Les colonnes de type hierarchyid peuvent être utilisées sur une table répliquée. La configuration requise pour votre application varie si la réplication est unidirectionnelle ou bidirectionnelle, et selon les versions de SQL Server qui sont utilisées.
Réplication unidirectionnelle
La réplication unidirectionnelle inclut la réplication d’instantanés, la réplication transactionnelle et la réplication de fusion dans laquelle les modifications ne sont pas apportées à l’Abonné. Le fonctionnement des colonnes hierarchyid avec la réplication unidirectionnelle dépend de la version de SQL Server exécutée par l’abonné.
Un serveur de publication SQL Server peut répliquer des colonnes hierarchyid vers un abonné SQL Server sans considération spéciale.
Un serveur de publication SQL Server doit convertir des colonnes hierarchyid pour les répliquer sur un Abonné exécutant SQL Server Compact ou une version antérieure de SQL Server. SQL Server Compact et les versions antérieures de SQL Server ne prennent pas en charge les colonnes hierarchyid . Si vous utilisez l’une de ces versions, vous pouvez toujours répliquer des données sur un Abonné. Pour ce faire, vous devez définir une option de schéma ou le niveau de compatibilité de la publication (pour la réplication de fusion) afin que la colonne puisse être convertie en un type de données compatible.
Le filtrage de colonne est pris en charge dans ces deux scénarios. Cela inclut l’exclusion des colonnes hierarchyid. Le filtrage de lignes est pris en charge tant que le filtre n’inclut pas de colonne hierarchyid .
Réplication bidirectionnelle
La réplication bidirectionnelle inclut la réplication transactionnelle avec mise à jour des abonnements, la réplication transactionnelle d'égal à égal et la réplication de fusion dans laquelle les modifications sont apportées au niveau de l'abonné. La réplication vous permet de configurer une table avec des colonnes hierarchyid pour la réplication bidirectionnelle. Notez la configuration requise et les considérations suivantes :
Le serveur de publication et tous les Abonnés doivent exécuter la même version, sur SQL Server 2016 (13.x) ou une version ultérieure.
La réplication réplique les données sous forme d’octets et n’effectue aucune validation pour garantir l’intégrité de la hiérarchie.
La hiérarchie des modifications apportées à la source (Abonné ou Serveur de publication) n’est pas conservée lorsqu’elles sont répliquées vers la destination.
Les valeurs des colonnes hierarchyid peuvent avoir des représentations binaires identiques sur toutes les bases de données. Les conflits peuvent se produire dans la réplication bidirectionnelle lorsque la logique d’application génère indépendamment le même hierarchyid pour différentes entités. Par conséquent, la même valeur pourrait être générée sur le serveur de publication et l'abonné, mais pourrait être appliquée sur des lignes différentes. La réplication ne vérifie pas cette condition et il n’existe aucun moyen intégré de partitionner les valeurs de colonne hierarchyid , car il existe des
IDENTITYcolonnes. Les applications doivent utiliser des contraintes ou d'autres mécanismes pour éviter de tels conflits non détectés.Il est possible que les lignes insérées sur l’Abonné puissent être orphelines. La ligne parente de la ligne insérée peut être supprimée sur le serveur de publication. Cela provoque un conflit non détecté lorsque la ligne de l'abonné est insérée au niveau du serveur de publication.
Les filtres de colonnes ne peuvent pas filtrer les colonnes hierarchyid non nullables. Les insertions de l’Abonné échouent, car il n’existe aucune valeur par défaut pour la colonne hierarchyid sur le serveur de publication.
Le filtrage de lignes est pris en charge tant que le filtre n’inclut pas de colonne hierarchyid .