有人在生产中使用HierarchyId吗？它可靠吗？

是否有人在实际生产中使用HierarchyId，并且表的大小合理，有几千行？它可靠/性能好吗？到目前为止，我还没有发现任何与该供应商无关的人推荐它，Paul Nielsen 在此建议不要这样做。

您在实际生产系统中使用HierarchyId有什么经验？

在选择HierarchyId替代方案时使用了哪些条件？

我已经实现了HierarchyID，发现它提供了良好的性能并且易于使用。

我已经在相对较小的数据集（成千上万的行）中使用了它，层次结构多达10个分支。

为什么要使用它？HierarchyID类型提供了许多辅助方法（例如IsDescendantOf），这些方法使您的工作比滚动自己的物化路径更容易。

在StackOverflow上保罗尼尔森的评论会搞乱我- HIERARCHYID 是一个物化路径。我更倾向于在他的回答下面同意这一评论。

一个更好的问题可能是“为什么不使用它”。它易于使用，提供了许多您自己为自己编写的功能，并且表现出色（在我有限的测试中）。

这是对柯克的问题“为什么不使用它（HierarchyId）”的回答。与物化路径相比，在某些重要情况下，HierarchyId似乎性能较低，使用起来也不方便。

原因很简单：引用Microsoft在Connect上的评论，“问题是CLR调用（包括architectureID的方法）对于查询优化器是不透明的。这是设计使然。但是，这意味着它们的基数估计有时可能相当错误。”

另一方面，实现物化路径在我们第一次需要执行时非常容易，而下次它实质上是一项复制粘贴任务。因此，我们只需很少的努力即可获得功能更广泛，性能更好的解决方案。

因此，我完全同意保罗·尼尔森（Paul Nielsen）的观点，他在其出色的著作《Microsoft®SQLServer®2008圣经》中写道：“新的HierarchyID并非没有争议。它是新的，并且得到了大量的媒体报道和演示时间，但是我我不确定这是需要其他解决方案的问题。”

我的公司在直销，多层营销软件中使用HeirachyID。有用。我实际上并没有做任何工作，只是知道我们正在使用它。

我看到的最大问题是，我们以循环的方式遍历各个关卡，而不是基于集合。在那方面，它对我们来说并不是很好，但是我不确定这是类型还是我们的实现有问题。

architectureid的一个问题是您会锁定供应商。但是我确实找到了亚当·米拉佐（Adam Milazzo）撰写的一篇很棒的文章，内容涉及一切内部运作方式：

http://www.adammil.net/blog/view.php?id=100

有了这个，我能够编写一个Postgres脚本来将我的数据集从MSSQL转换过来。还将它包含在我编写的将AdventureWorks数据库导入Postgres的脚本中：

https://github.com/lorint/AdventureWorks-for-Postgres

只需在那里的install.sql文件中搜索“ hierarchyid”，您很快就会找到转换它的参考。

我们的团队已经在生产中实现了它，起初性能不错，两年后，该表现在包含430,000行，getroot和getdecendent花费3秒，这两个都是计算下一个插入记录的Id值所必需的。现在，单个子树插入大约需要16秒，这根本是不可接受的。