階層データを SQL に保存しようとしていますが、使用することにしました
- すべてのメインデータが格納されるオブジェクトテーブル
- オブジェクト間の関係を定義するクロージャ テーブル (クロージャ テーブルの詳細については、こちら [スライド 40 ～ 68] を参照してください)。
かなりの調査の後、クロージャーテーブルが私のニーズによく合っているように見えました。ただし、私が読み続けていることの 1 つは、特定のノードの直接の祖先/子孫を照会する場合はdepth、クロージャー テーブルの列を使用できるということです (上記のリンクのスライド 68 を参照)。depthこの正確なタイプのクエリを容易にするために、この列が必要です。これはすべてうまくいっていますが、そもそもクロージャー テーブルの主な魅力の 1 つは、そこに含まれるデータのクエリと変更の両方depthを簡単に実行できることでした。データを変更できます (新しいノードを追加し、ツリーのブランチ全体をオフセットすることを想像してください)。
そのため、ノードとその直接の祖先/子孫の間の関係のみを定義するようにクロージャー テーブルを変更することを検討しています。これにより、ツリーを簡単にトラバースできます。データのクエリは比較的簡単に思えます。データの変更は、フィールドのない元のクロージャ テーブルほど簡単ではありませんが、depthフィールドのあるものよりははるかに簡単ですdepth。公正な妥協のように思えます (ほぼクロージャ テーブルと隣接リストの間)。
私は何かを見落としていますか？このようにすることで、クロージャ テーブルの重要な利点の 1 つを失っていますか? 後で私を悩ませるようになるかもしれないこの方法でそれを行うことに固有のリスクを誰かが見ていますか?