2017-06-11 2 views
1

私はツリーのような階層を表すためにSQLスキーマを作成していますが、このツリーは決してNレベルの深さ以上ではないことがわかりますアプリケーションの設計、最も可能性が高いのは約4または5)。SQLで固定深度ツリーをモデリングする

このツリーの深さが固定されている場合は、ツリーの各レベルを表としてモデル化してアプリケーションを設計する方が良いでしょうか?あるいは、任意の深さ(例えば、隣接リストやネストセット)を考慮してアプローチする方が良いでしょうか?

純粋にクエリ可能性の観点から質問しています。さまざまなレベルのツリーを報告します。

答えて

1

よく知られている階層構造(node_id, parent_id)と追加の列depthの1つのテーブルを使用します。この列は理論的には冗長ですが、特定のツリーレベルのクエリに非常に役立ちます。もちろん、このような構造では、再帰クエリを使用してツリーを上から下に(またはその逆に)簡単に移動することができます。

create table a_tree(
    node_id int primary key, 
    parent_id int, 
    depth int 
-- other columns 
); 

ボーナスとして、SOのこのタイプのテーブルの多くのすぐに使用できるソリューションがあります。

+0

ツリーの深さが決して拡大しないことがわかっている場合は、単一のテーブル対5テーブルを使用して_disadvantages_というクエリがありますか? – J3Y

+1

5つのテーブルを使用する代わりに、単一のテーブルを使用して5回だけ結合することができます。私自身の経験から、将来的には成長する可能性があります。このアプローチでは、WITH RECURSIVEクエリを使用して拡張し、ディスク容量を節約しましょう。 –

+1

@ J3Y - 逆に、1つではなく複数のテーブルを使用することに多くの不便があります。たとえば、データに影響するビュー、関数、トリガーなどを定義することを考えてみましょう。 – klin

関連する問題