0

他の 2 つの間で新しい HierarchyID を要求すると、結果が徐々に長くなります。たとえば、2/5.6 と 2/5.7 の間には、2/5.6.1 と他の 4 つのコンポーネント パスしかありません。HierarchyID データ型は 800 バイトに制限されているため、これを永遠に繰り返すことはできません。繰り返しになりますが、整数型も制限されていますが、実際には問題ありません。高さが無制限に大きくならないように、テーブルを定期的に最適化する必要がありますか?

4

1 に答える 1

1

hierarchyid間の状態 ( など) をまったく使用しないように、新しい ID を「追加」することが「ベスト プラクティス」と見なさ/2/5.6/れます。クラスター化された主キーである場合、hierarchyidパフォーマンスが低下し、意志と同様にページ分割が発生しますuniqueidentifier。

シーケンシャルな子を生成する場合、不足を心配する必要はほとんどありません。親ごとに文字通り何百万もの子供を持つことができます。

hierarchyid値を生成する方法の例を次に示します。

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION 
    UPDATE Hierarchy
    SET @LastChild = LastChild = HId.GetDescendant(LastChild, NULL)
    WHERE HId = @ParentID

    INSERT Hierarchy (HId, ...)
    VALUES (@LastChild, ...)
COMMIT

この方法で ID を生成すれば、ID が不足する心配はありませんのでご安心ください。

好奇心のために、簡単なテストを実行して、どれだけ深くまで行けるかを確認しました. テストスクリプトは次のとおりです。

DECLARE
    @parent hierarchyid,
    @child hierarchyid,
    @high hierarchyid,
    @cnt int

SET @parent = '/1/'
SET @child = @parent.GetDescendant(NULL, NULL)
SET @cnt = 0

WHILE (@@ERROR = 0)
BEGIN
    SET @cnt = @cnt + 1
    PRINT CAST(@cnt AS varchar(10)) + ': ' + @child.ToString()
    SET @high = @parent.GetDescendant(@child, @high)
    SET @child = @parent.GetDescendant(@child, @high)
END

1426 のポイント ネスティング レベルでエラーが発生することがわかります。これは、作成できる「中間」ノードの数の最悪の場合の制限です。最悪の場合は、すべての挿入が 2 つの最も深い間に入ることを意味します。ネストされたノード。

コメントで述べたように、この制限に達するのはかなり難しいですが、それでも試してみるのは良い考えではありません. 実際のバイト長は、使用する「ポイント」が増えるほど長くなり、パフォーマンスが低下します。hierarchyidがクラスター化インデックスである場合、これによりページ分割によるパフォーマンスが低下します。ノードを親でランク付けしようとしている場合は、代わりにランキング列を使用してください。トランザクションの分離やその他の頭痛の種を心配しなければならないときに行うよりも、後でソートする方が簡単で効率的です。SELECTINSERT

于 2010-05-15T14:47:49.170 に答える