A la vue des performances de cette simple requête, on peut ne pas avoir la moindre hésitation pour utiliser le type HierarchyID dans la modélisation des arborescences dans une structure relationnelle. Le nouveau type remplit ses fonctions et de façon prometteuse car il concentre des informations qui nécessitaient des requêtes plus ou moins complexes (IsDescendant, GetDescendant, etc.) ou l'utilisation de champs techniques (GetLevel, GetAncestor, etc.).

Cependant, sans vouloir jouer les « troubles paix », je vous invite à garder les pieds sur terre et à considérer l'utilisation de ce nouveau type avec sagesse (ie. uniquement s'il répond à vos besoins). En effet, le type HierarchyID induit quelques inconvénients. En premier lieu, ce type est plus technique et donc plus difficile à utiliser et à maintenir. Il me rappelle l'arrivée des délégués anonymes en C# 2.0 ; tout le monde trouvait cela génial mais beaucoup se cassaient les dents en tombant dessus dans du vrai code. Aussi, la lecture des champs de ce type est beaucoup moins triviale et on doit vite requêter en T-SQL pour interpréter un jeu de données (là je pense à mes collègues trop prompts à utiliser les wizards de Management Studio ).

En second lieu et c'est certainement le point le plus important, c'est qu'à l'usage, ce nouveau type peut s'avérer pénalisant, même au niveau des performances. Par exemple, l'insertion est plus complexe et demandeuse en CPU. Je vous invite donc à bien analyser vos besoins, vos requêtes types, de maquetter et seulement après de statuer sur l'utilisation de ce champ. Vous conviendrez d'ailleurs que cette remarque s'applique à toute technologie ou projet informatique.

Cependant, voici quelques pistes pour vous aider dans vote choix. Une modélisation plus classique restera conseillée dans les cas suivants: Quand la taille de la clé est importante ; en effet, même s'il est compact par rapport aux informations stockées, on peut vite dépasser les 4 octets d'un simple entierQuand on requête principalement et de façon atomique les éléments de la hiérarchie ; dans ce cas, une clé primaire ou un index unique répondront mieux au besoinQuand on doit souvent déplacer des éléments qui ne sont pas des feuilles de l'arborescence ; les insertions et les mises à jour sont plus lentes avec le type HierarchyID