いつものように：最善の解決策はありません。それぞれのソリューションは、さまざまなことを簡単または困難にします。適切な解決策は、最も実行する操作によって異なります。
親IDを使用した単純なアプローチ：
長所：
-
実装が簡単
-
大きなサブツリーを別の親に簡単に移動できます
-
インサートが安い
-
SQLで直接アクセスできる必要なフィールド
短所：
-
ツリー全体の取得は再帰的であるため、コストがかかります
-
すべての親を見つけることもコストがかかります（SQLは再帰を認識しません...）
変更されたプレオーダーツリートラバーサル（開始点と終了点を保存）：
長所：
-
ツリー全体を取得するのは簡単で安価です
-
すべての親を見つけるのは安いです
-
SQLで直接アクセスできる必要なフィールド
-
ボーナス：親ノード内の子ノードの順序も保存しています
短所：
- 多くのノードを更新する必要がある場合があるため、挿入/更新には非常にコストがかかる可能性があります
各ノードにパスを保存する：
長所：
-
すべての親を見つけるのは安いです
-
ツリー全体を取得するのは安価です
-
挿入は安いです
短所：
-
ツリー全体を移動するにはコストがかかります
-
パスを保存する方法によっては、SQLで直接操作することはできないため、パスを変更する場合は、常にパスをフェッチして解析する必要があります。
クロージャーテーブル
長所：
-
実装が簡単
-
すべての親を見つけるのは安いです
-
挿入は安いです
-
木全体を取得するのは安価です
短所：
-
追加のテーブルが必要です
-
他のアプローチと比較して多くのスペースを占有します
-
サブツリーの移動にはコストがかかります
データが変更される頻度に応じて、最後の2つのうちの1つを選択します。
参照： http://media.pragprog.com/titles/bksqla/trees pdf