64

ディレクトリ/階層/ツリー構造をデータベースに保存するにはどうすればよいですか? つまり、MSSQL サーバーです。

@olavk：あなたが私自身の答えを見たようには見えません。私が使用する方法は、再帰クエリよりも優れています:)

ppsこれが行く方法です！

4

8 に答える 8

21

SQLデータベースに階層を格納する方法はたくさんあります。どちらを選択するかは、使用するDBMS製品とデータの使用方法によって異なります。MSSQL2005タグを使用したので、「隣接リスト」モデルの検討を開始する必要があると思います。アプリケーションでうまく機能しない場合は、Vadim Tropashkoの比較をご覧ください。これは、複数のパフォーマンス特性に焦点を当てたモデル間の違いを強調しています。

于 2008-09-27T20:27:59.067 に答える
8

Sql Server 2008 を使用するオプションがある場合: おそらく、新しいhierarchyidデータ型を確認する必要があります。

于 2008-11-17T14:09:03.603 に答える
5

また、ParentID モデルよりもいくつかの利点があるツリーのネスト セット モデルもあります。http://www.evanpetersen.com/item/nested-sets.htmlおよびhttp://falsinsoft.blogspot.nl/2013/01/tree-in-sql-database-nested-set-model.htmlを参照してください。

于 2008-09-27T20:23:08.613 に答える
3

これは私にとって質問というよりはブックマークのようなものですが、あなたにも役立つかもしれません. この記事のアプローチを使用して、ディレクトリ/ツリー構造をデータベースに格納しました。

この記事には、いくつかの便利なコード スニペットもあります。

お役に立てれば。

私は決してそのウェブサイトと提携していません

于 2008-09-27T19:59:32.273 に答える
3

SQL Server 2005 を使用していますか? 再帰クエリにより、階層データのクエリがより洗練されたものになります。

編集：具体化されたパスは少しハックだと思います。パスには正規化されていない冗長データが含まれており、トリガーなどを使用して更新を維持する必要があります。例えば。ノードが親を変更した場合、サブツリー全体のパスを更新する必要があります。また、サブツリー クエリは、エレガントで高速な結合ではなく、醜いサブストリング マッチングを使用する必要があります。

于 2008-09-27T20:14:31.457 に答える
3

私のプロジェクトの1つで同様の問題に直面しました。私たちは、永遠に増え続ける巨大なヒエラルキーを持っていました。私はそれを素早く横断し、いくつかの複雑な検証の後に適切なグループを見つける必要がありました. SQL Server に行って頭を悩ませるのではなく、再帰クエリが唯一の実行可能なソリューションであることがわかっているときに、そこで効率的にそれを行うにはどうすればよいでしょうか。しかし、再帰クエリで可能な最適化があるかどうか本当に知っていますか? 階層が今後増加しないという保証はありますか? ある晴れた日、再帰クエリが遅すぎて本番環境で使用できないことがわかりましたか?

そこで、Neo4J を試してみることにしました。これは、多くの有用なアルゴリズムが組み込まれたグラフ データベースであり、適切なドキュメントと例を備えた驚くほど高速なトラバーサルです。階層を Neo4J に保存し、Thrift Service (またはその他のもの) を使用して階層にアクセスします。はい、SQL クエリを Neo4J と統合するコードを作成する必要がありますが、スケーラブルで将来性の高いソリューションが得られます。

これが役に立つことを願っています。

于 2011-10-14T18:01:37.047 に答える
2

質問は、閉じられたこの質問に似ています。両方の質問への回答が私の追求に非常に役立つことがわかり、最終的に、ツリー構造をモデル化する 5 つの異なる方法を提示する MongoDB マニュアルにたどり着きました: https://docs.mongodb.com/manual/applications/data-models-tree -構造物/

MongoDB はリレーショナル データベースではありませんが、提示されたモデルはリレーショナル データベースだけでなく、JSON などの他の形式にも適用できます。提示された長所と短所に基づいて、どのモデルが正しいかを明らかにする必要があります。

この質問の著者は、親モデルとマテリアライズド パス モデルの両方を組み合わせたソリューションを見つけました。深さと親を維持すると、いくつかの問題 (余分なロジック、パフォーマンス) が発生する可能性がありますが、特定のニーズには明らかに利点があります。私のプロジェクトでは、具体化されたパスが最適に機能し、この記事の手法を使用していくつかの問題 (並べ替えとパスの長さ) を克服しました。

于 2017-01-06T00:02:06.563 に答える
1

典型的な方法は、それ自体に外部キー (「ParentId」など) を持つテーブルです。

于 2008-09-27T20:17:49.997 に答える