本番環境でHierarchyIdを使用している人はいますか？信頼できますか？
数千行を超える妥当なサイズのテーブルを含む実際の本番環境でHierarchyIdを使用している人はいますか？信頼できる/パフォーマンスはありますか？これまでのところ、ベンダーに関係のない人がそれを推奨していることは見つかりませんでした。PaulNielsenはそれに対してアドバイスします here 。
実際の本番システムでHierarchyIdを使用した経験はありますか？
代わりにHierarchyIdを選択したとき、どの基準を使用しましたか？
HierarchyIDを実装しましたが、それが優れたパフォーマンスと使いやすさを提供することがわかりました。
私はそれを10ブランチまでの階層を持つ比較的小さなデータセット（数万行）で使用しました。
なぜそれを使うのですか？ HierarchyIDタイプは、独自のマテリアライズドパスをロールするよりもジョブを簡単にするいくつかのヘルパーメソッド（IsDescendantOfなど）を提供します。
StackOverflowに関するPaul Nielsenのコメントは私を混乱させます-HierarchyIDは実体化されたパスです。私は彼の答えの下で このコメント に同意する傾向があります。
より良い質問は、「なぜそれを使わないのか」でしょう。使い方は簡単で、他の方法で自分用に作成する多くの機能を提供し、（私の限られたテストでは）うまく機能します。
これは、カークの質問「なぜ使用しないのか（HierarchyId）」に対する回答です。実体化されたパスと比較して、いくつかの重要なケースでは、HierarchyIdはパフォーマンスが低く、操作するのに不便です。
理由は簡単です：引用 Connectに関するMicrosoftのコメントから 、 "問題は、hierarchyIDのメソッドを含むCLR呼び出しがクエリオプティマイザーに対して不透明であることです。これは、設計。ただし、それらのカーディナリティの見積もりは、かなり間違っていることがあります。」
一方、実体化されたパスの実装は、初めて実行する必要があるときは非常に簡単で、次回は基本的にコピーアンドペーストタスクになります。したがって、私たちは非常に少ない労力で、より用途が広く、パフォーマンスの高いソリューションを手に入れます。
したがって、「Microsoft®SQLServer®2008 Bible」というタイトルの優れた本で次のように書いたPaul Nielsenと完全に同意します： "新しいHierarchyIDには論争がないわけではありません。プレスとデモの時間ですが、別の解決策が必要だった問題かどうかはわかりません。」
私の会社では、直販のマルチレベルマーケティングソフトウェアでHeirachyIDを使用しています。できます。私は実際にそれを使った作業はしていません。私たちはそれを使用していることを知っています。
私が見た最大の問題は、より多くのセットベースではなく、ループ方式でレベルを反復処理していることです。その領域では、実際にはうまく機能しませんが、それがタイプまたはそれの実装に問題があるかどうかはわかりません。
Hierarchyidの1つの問題は、ベンダーロックインを取得することです。しかし、私はすべてが内部でどのように機能するかについて、Adam Milazzoによる素晴らしい記事を見つけました。
http://www.adammil.net/blog/view.php?id=1
これにより、データセットをMSSQLから変換するPostgresスクリプトを記述できました。また、AdventureWorksデータベースをPostgresにインポートするために記述したスクリプトにも含まれています。
https://github.com/lorint/AdventureWorks-for-Postgres
そこにあるinstall.sqlファイルで「hierarchyid」を検索するだけで、すぐにそれを変換するための参照が見つかります。
私たちのチームはそれを本番環境に実装しました。最初はパフォーマンスは良好です。2年後、テーブルには430,000行が含まれ、getrootとgetdecendentには3秒かかります。これらは両方とも、レコードを挿入するための次のId値の計算に必要です。現在、単一のサブツリーの挿入には約16秒かかりますが、これはまったく受け入れられません。