|
Cet article a fait l'objet d'une traduction manuelle. Déplacez votre pointeur sur les phrases de l'article pour voir la version originale de ce texte.
|
Traduction
Source
|
hierarchyid (Transact-SQL)
-
Extrêmement compact Le nombre moyen de bits qui sont requis pour représenter un nœud dans une arborescence avec n nœuds dépend de la sortance moyenne (le nombre moyen d'enfants d'un nœud). Pour les petites sortances (de 0 à 7), la taille est d'environ 6*logAn bits, où A est la sortance moyenne. Un nœud dans une hiérarchie d'organisation de 100 000 personnes avec une sortance moyenne de 6 niveaux prend approximativement 38 bits. Ce chiffre est arrondi à 40 bits, ou 5 octets, pour le stockage. -
La comparaison est effectuée dans l'ordre à profondeur prioritaire Étant donné deux valeurs hierarchyida et b, a<b signifie que a se situe avant b dans un parcours à profondeur prioritaire de l'arborescence. 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 En utilisant la méthode GetDescendant, il est toujours possible de générer un frère à droite d'un nœud donné, à gauche d'un nœud donné, ou entre les 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 produiront des valeurs hierarchyid avec une représentation légèrement moins compacte. -
L'encodage utilisé dans le type hierarchyid 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.
-
/ -
/1/ -
/0.3.-7/ -
/1/3/ -
/0.1/0.2/
-
Utilisez la méthode ToString() pour convertir la valeur hierarchyid en représentation logique comme un type de données nvarchar(4000). -
Utilisez Read () et Write () pour convertir hierarchyid en varbinary. -
La conversion de hierarchyid en XML n'est pas prise en charge. Pour transmettre des paramètres hierarchyid par SOAP, convertissez-les d'abord en chaînes. Une requête avec la clause FOR XML échouera sur une table avec hierarchyid à moins que la colonne ne soit d'abord convertie en type de données character.
Réplication unidirectionnelle
-
Un serveur de publication SQL Server 2012 peut répliquer des colonnes hierachyid vers un abonné SQL Server 2012 sans considération spéciale. -
Un serveur de publication SQL Server 2012 doit convertir les colonnes hierarchyid pour les répliquer vers un abonné qui exécute SQL Server Compact ou une version antérieure de SQL Server. SQL Server Compact et les versions précédentes de SQL Server ne prennent pas en charge les colonnes hierarchyid. Si vous utilisez l'une de ces versions, vous pouvez encore répliquer des données vers 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.
Réplication bidirectionnelle
-
Le serveur de publication et tous les abonnés doivent exécuter SQL Server 2012. -
La réplication réplique les données comme octets et n'effectue aucune validation pour assurer l'intégrité de la hiérarchie. -
La hiérarchie des modifications qui ont été 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 de hachage pour les colonnes hierarchyid sont spécifiques à la base de données dans laquelle elles sont générées. 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 aucune méthode intégrée pour partitionner les valeurs de la colonne hierarchyid comme c'est le cas pour les colonnes IDENTITY. 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 qui sont insérées sur l'abonné soient orphelines. La ligne parente de la ligne insérée a pu être supprimée au niveau du 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 colonne ne peuvent pas exclure les colonnes hierarchyid n'acceptant pas les valeurs NULL : les insertions de l'abonné échoueront, 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.
