問題タブ [nested-sets]

このスペースツリーでは、ネストされたセット構造（mysql）をjsonに変換する必要があります1）http://blog.thejit.org/wp-content/jit-1.0a/examples/spacetree.html

入れ子集合から配列を作成するこの関数を見つけました：2）http://semlabs.co.uk/journal/converting-nested-set-model-data-in-to-multi-dimension-arrays-in-php

PHP関数json_encodeを使用してphp配列をjsonに変換することもできます

私の問題：関数nestify（2番目のリンクから）は、私が必要としているものを正確に与えてくれません。私はこのようなものが必要です：http：//pastebin.com/m68752352

関数「nestify」を変更して正しい配列を取得するのを手伝ってもらえますか？

この関数をもう一度示します。

Rails アプリで「acts_as_nested_set」を使用しています。(すばらしいネストされたセット プラグインで拡張)。要素とそのネストされたセット全体を複製する関数/メソッドを作成して、各要素が複製されますが、新しい要素だけで関係構造が元の構造を模倣するようにする最善の方法を論理的に考えようとしていました。

ネストされたセットを使用すると、parent_id, lft, and rgt位置列が得られます... position_id.

各セットの最下部 (子のないノード) から開始し、親を介して新しいルートまでクローンを作成する必要がありますか?

これは、すでに行われたか、ネストされたセットに対してすでにこれを行う方法があるようですが、私を導くものを見つけることができません。

ありがとう

ネストされたセットモデルの MySQL テーブルからのデータを含む配列を取得しました。アルファベット順だけでなく、親ノードの直後の子ノードでも並べ替えたいと思います。例 - 並べ替える配列 (並べ替え前):

このように配列が必要です（ソート後）：

ご覧のとおり、id 2 の投稿の直後に親 2 を持つすべての投稿が必要です。

どんな助けでも大歓迎です。前もって感謝します。

ネストされたセット内でノードとそのすべての子を移動する MySQL クエリが必要です。私はこのサイトを見つけましたが、その関数は非常に非論理的なようです-ネストされたセットモデルが存在しないuniverseidか、存在せずtreeid、コード自体が必要と思われるものよりも長くなります. 私がテーブルに持っている唯一の余分な列はparent.

ID が失われるため、ノードを削除して再度追加することはできませんでした。

管理者のフラットリストよりも使いやすいものを提供することにより、django-mptt と contrib.admin を結び付けようとしています。ツリーは大きいはずなので (そうでなければネストされたセットを使用しないでしょう)、ユーザーはその一部を展開したり折りたたんだりできるはずです。

ユーザーがブランチを展開、折りたたみ、または展開すると (そのために ajax が使用されます)、折りたたまれたブランチのコンマ区切りリストを含む Cookie も設定されます。このようにして、次にこのユーザーが私の django-mptt を利用したモデルの管理者にアクセスしたときに、彼が残した正確な状態のツリーを彼に見せることができます。ここで、この折りたたまれたブランチのリストを使用して、ツリーの必要な部分のみを取得することでデータベースの負担を軽減したいと考えています。

これを効果的に行う方法はありますか？私がグーグルで検索したソリューションは、ブランチが折りたたまれたときにクエリを実行するのを避けることができるように、ブランチごとにクエリを作成していましたが、それはあまり効果的ではありません。固定数のクエリで可能でしょうか？

カテゴリモデルを作成し、awesome_nested_setプラグイン（の代わりacts_as_nested_set）を使用して階層を処理しています。を使用awesome_nested_setすると、オブジェクトが作成され、保存されてから、セット内に配置されます。同様に、、lftおよびrgtはparent_id直接attr_protected書き込むことができないためです。

ノードをキャッチできるようにしたいセットに配置して、ユーザーに通知するときに、2つの状況が発生しています（まだ考えていないことがあるかもしれません）。

1. ノードはそれ自身の子として配置されようとします（self.id == self.parent_id）
2. ノードは、それ自体の子孫の下に移動しようとします（self.descendants.include? self.parent_id == true）

どちらの場合も、移動は失敗しますがawesome_nested_set、例外が発生するだけでActiveRecord::ActiveRecordError、ユーザーに提供したいほど説明的ではないメッセージが表示されます。

awesome_nested_setには、すべてが呼び出すノード移動メソッドがいくつかありますmove_to(target, position)（ここで、はposition、、、またはのいずれかであり、はすべてのsに関連するノードです）。このメソッドはコールバックを起動しますが、移動が発生する前に検証する方法を提供していません。移動を検証するには、コールバックが受信しないターゲットと位置にアクセスする必要があります。:root:child:left:righttargetposition:rootbefore_move

入居を検証する方法awesome_nested_set（別のメソッドによってターゲットと位置をbefore_moveコールバックに渡す方法がある）、または検証できる別のネストされたセットプラグインのいずれかを知っている人はいますか？自分のプラグインをフォークしたり書いたりしたくない。

フラットなテーブル (SQL など) 内にツリーを格納するための修正された事前注文ツリー トラバーサルアルゴリズムについて考えてきました。

標準的なアプローチで私が気に入らない点の 1 つは、ノードを挿入するには、(平均して) N/2 のノード (挿入ポイントより左または右が高いすべて) に触れなければならないことです。

私が見た実装は、順番に番号が付けられた値に依存しています。これにより、更新の余地がなくなります。

これは、並行性とスケーリングにとって悪いようです。大規模なシステムのすべてのアカウントのユーザー グループを含む世界に根ざしたツリーがあるとします。これは非常に大きく、ツリーのサブセットを別のサーバーに保存する必要があります。ツリーの一番下にノードを追加するために、すべてのノードの半分に触れるのは良くありません。

そこで考えた案がこちら。基本的に、キースペースを分割し、各レベルで分割することにより、挿入の余地を残します。

_{N max} = 64の例を次に示します (これは通常、DB の MAX_INT になります)

ここでは、ツリーの左半分にノードが追加されます。

サブツリーの左/右のインデックスに再帰的に番号を付け直すには、挿入および削除プロセスのアルゴリズムを拡張する必要があります。ノードの直下の子のクエリは複雑なので、親 ID もテーブルに格納するのが理にかなっていると思います。次に、アルゴリズムはサブツリーを選択し (left > p.left && right < p.right を使用)、node.id と node.parent を使用してリストを処理し、インデックスを分割します。

これは、単にすべてのインデックスをインクリメントして挿入用のスペースを作る (または削除用にデクリメントする) よりも複雑ですが、はるかに少ないノード (挿入/削除されたノードの親の子孫のみ) に影響を与える可能性があります。

私の質問は基本的に次のとおりです。

1. このアイデアは形式化または実装されていますか?

2. これはネストされた間隔と同じですか?