本番環境でHierarchyIdを使用している人はいますか？信頼できますか？

数千行以上の適切なサイズのテーブルで、実際の運用でHierarchyIdを使用している人はいますか？信頼性/性能はありますか？これまでのところ、ベンダーと提携していない人がそれを推奨しているのを発見していません。PaulNielsenはここでこれに反対しています。

実際の運用システムでHierarchyIdを使用した経験は何ですか？

代わりにHierarchyIdを選択したときに、どの基準を使用しましたか？

HierarchyIDを実装しましたが、優れたパフォーマンスと使いやすいことがわかりました。

階層が最大10ブランチの比較的小さなデータセット（数万行）で使用しました。

使用する理由 HierarchyIDタイプは、IsDescendantOf独自のマテリアライズドパスをロールするよりもジョブを簡単にする多くのヘルパーメソッド（など）を提供します。

StackOverflowの上のオーバーポール・ニールセンさんのコメントは私に混乱している- hierarchyid型があるマテリアライズドパス。私は彼の答えの下にあるこのコメントにもっと同意したいです。

より良い質問は、「なぜ使用しないのか」です。使い方は簡単で、他の方法では自分で書くことになる多くの機能を提供し、うまく機能します（私の限られたテストでは）。

これは、Kirkの質問「なぜ使用しないのか（HierarchyId）」に対する回答です。実体化されたパスと比較して、いくつかの重要なケースでは、HierarchyIdのパフォーマンスが低下し、操作の利便性が低下しているようです。

理由は単純です：Connectに関するMicrosoftのコメントから引用すると、「問題は、hierarchyIDのメソッドを含むCLR呼び出しがクエリオプティマイザーに対して不透明であるということです。これは仕様によるものです。しかし、違う。"

一方、マテリアライズドパスの実装は、初めて行うときに非常に簡単であり、次回は本質的にコピーアンドペーストのタスクです。そのため、非常に少ない労力で、より汎用性が高くパフォーマンスの高いソリューションが得られます。

ポールニールセンは、「Microsoft®SQLServer®2008 Bible」というタイトルの優れた本で次のように書いています。「新しいHierarchyIDには議論の余地がないわけではありません。別の解決策が必要なのかどうかわからない」

私の会社では、直接販売のマルチレベルマーケティングソフトウェアでHeirachyIDを使用しています。できます。私はそれを実際に使ったことはありませんが、私たちはそれを使っていることを知っています。

私がこれまでに見た最大の問題は、セットベースではなく、ループ形式でレベルを繰り返し処理していることです。その領域では、それは私たちにとって実際にはうまく機能しませんが、それが型またはそれの実装に問題があるかどうかはわかりません。

hierarchyidの1つの問題は、ベンダーのロックインを取得することです。しかし、私はすべてが内部でどのように機能するかについてのAdam Milazzoによる素晴らしい記事を見つけました

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

これにより、MSSQLからデータセットを変換するPostgresスクリプトを作成できました。また、AdventureWorksデータベースをPostgresにインポートするために作成したスクリプトにそれを含めました。

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

そこのinstall.sqlファイルで「hierarchyid」を検索するだけで、すぐに変換への参照が見つかります。

私たちのチームは本番環境でそれを実装しました。最初はパフォーマンスが良好で、2年後、テーブルには430,000行が含まれ、getrootとgetdecendentには3秒かかります。どちらもレコードを挿入するための次のId値の計算に必要です。現在、単一のサブツリーの挿入には約16秒かかりますが、これはまったく受け入れられません。