Quelqu'un utilise-t-il HierarchyId en production réelle avec des tables de taille raisonnable, plus de quelques milliers de lignes? Est-ce fiable / performant? Jusqu'à présent, je n'ai trouvé personne non affilié au fournisseur qui le recommande, et Paul Nielsen déconseille cela ici .
Quelle est votre expérience de l'utilisation de HierarchyId dans des systèmes de production réels?
Quels critères avez-vous utilisés lorsque vous avez choisi HierarchyId plutôt que ses alternatives?
Réponses:
J'ai implémenté HierarchyID et l'ai trouvé pour fournir de bonnes performances et facile à utiliser.
Je l'ai utilisé sur des ensembles de données relativement petits (des dizaines de milliers de lignes) avec une hiérarchie jusqu'à 10 branches de profondeur.
Pourquoi l'utiliser? Le type HierarchyID fournit un certain nombre de méthodes d'assistance (telles que IsDescendantOf) qui rendent votre travail plus facile que de rouler votre propre chemin matérialisé.
Le commentaire de Paul Nielsen sur StackOverflow est déroutant pour moi - le HierarchyID est un chemin matérialisé. Je suis plus enclin à être d'accord avec ce commentaire sous sa réponse.
Une meilleure question pourrait être «pourquoi ne pas l'utiliser». Il est facile à utiliser, offre de nombreuses fonctionnalités que vous auriez autrement écrites pour vous-même et fonctionne bien (dans mes tests limités).
Ceci est une réponse à la question de Kirk «pourquoi ne pas l'utiliser (HierarchyId)». Par rapport au chemin matérialisé, dans certains cas importants, HierarchyId semble à la fois moins performant et moins pratique à utiliser.
La raison est simple: citant un commentaire de Microsoft sur Connect , "Le problème est que les appels CLR, y compris les méthodes hierarchyID, sont opaques pour l'optimiseur de requête. C'est de par leur conception. Cependant, cela signifie que l'estimation de cardinalité pour eux peut parfois être assez faux."
D'un autre côté, l'implémentation d'un chemin matérialisé est très facile la première fois que nous devons le faire, et la prochaine fois c'est essentiellement une tâche de copier-coller. Nous obtenons donc une solution plus polyvalente et plus performante avec très peu d'efforts.
Je suis donc entièrement d'accord avec Paul Nielsen, qui a écrit dans son excellent livre intitulé "Microsoft® SQL Server® 2008 Bible" comme suit: "Le nouveau HierarchyID n'est pas sans controverse. Il est nouveau et reçoit beaucoup de temps de presse et de démonstration, mais je ' Je ne suis pas sûr que ce soit un problème qui nécessitait une autre solution. "
Mon entreprise utilise HeirachyID dans la vente directe, un logiciel de marketing à plusieurs niveaux. Ça marche. Je n'ai pas vraiment fait de travail avec, je sais juste que nous l'utilisons.
Le plus gros problème que j'ai vu est que nous parcourons les niveaux en boucle au lieu d'être plus basés sur des ensembles. Dans ce domaine, il ne fonctionne pas vraiment bien pour nous, mais je ne suis pas sûr que ce soit un problème avec le type ou notre implémentation.
Un problème avec hierarchyid est que vous obtenez le verrouillage du fournisseur. Mais j'ai trouvé un excellent article d'Adam Milazzo sur la façon dont tout fonctionne en interne:
http://www.adammil.net/blog/view.php?id=100
Avec cela, j'ai pu écrire un script Postgres pour convertir mon ensemble de données à partir de MSSQL. Je l'ai également inclus dans un script que j'ai écrit pour importer la base de données AdventureWorks dans Postgres:
https://github.com/lorint/AdventureWorks-for-Postgres
Recherchez simplement "hierarchyid" dans le fichier install.sql et vous trouverez bientôt des références pour le convertir.
Notre équipe l'a implémenté en production, au début les performances sont bonnes, après 2 ans, la table contient maintenant 430 000 lignes et getroot et getdecendent prennent 3 secondes, les deux sont nécessaires pour calculer la prochaine valeur Id pour l'insertion de l'enregistrement. Maintenant, une seule insertion de sous-arbre prend environ 16 secondes, ce qui n'est pas acceptable du tout.