シンプルな Web ナビゲーション メニューを SQL Server 2012 に保存したいと考えています。これは複数のクライアントに対して行われるため、保存する必要があります。メニュー項目にも順序が必要です。これにより、クライアントが希望する方法で注文できるようになります。私は SQL Server の HierarchyId データ型について調べてきましたが、私が見つけたほとんどすべてのチュートリアルは、従業員または企業階層の例を使用しており、最上位に 1 つのルート ノードがあります。何時間も読んでテストした結果、HierarchyId はリンクの単純なナビゲーション メニューに最適なツールではないかもしれないという感覚に襲われました。私はこの気持ちでオフですか？
HierarchyId について気付いた主な懸念点は、HierarchyId を持つルート ノードは 1 つしか持てないことです。しかし、ナビゲーション メニューを使用すると、子を持つことができる最上位の "ルート ノード" が複数存在することは明らかです。また、ルート ノードには順序がないため ("/" のみ)、クライアントはトップレベルのメニュー リンクを移動できません。
したがって、明白な選択は、ダミーのルート ノードを作成し、すべてのトップレベル メニュー リンクをそのルート ノードの下に配置することです。しかし、この SO questionによると、marc_s と Jeremy は、複数の第 1 レベルのノードを持つためだけに、人工的な「über-root」ノードを作成するのは珍しい (または HierarchyId の通常の使用法によらない) ように思わせます。そして、この「über-root」ノードを実行することで、SQL サーバーの GetLevel() 関数も破棄していませんか?「最上位」ノードが 0 ではなくレベル 1 として表示されるためです。
各行に ParentId を格納し、C# で再帰を使用してメニュー階層を構築する方法を考えています。そうするのは間違っていますか？HierarchyId データ型は本当にこのような状況に適しているのでしょうか? 何か足りないのでしょうか?