1

thisのような json ネストされたオブジェクトがあります。

私の場合、idint型の一意のフィールドがあります（代わりにname上記を使用してください）。これは二分木ではありませんが、より親子関係を表しています。say に根ざした子ツリ​​ー (子) を簡単に検索する方法が必要id = 121でした。強引な方法で、ノードが見つかるまですべてのノードを比較し、子を返すことができます。しかし、{id, node} のマップを保持することを考えていました。たとえば{"121" : root[1][10]..[1]}。これは、メモリの無駄遣いになる可能性があります (配列へのポインターを使用しない限り)。より良い方法があることに注意してください。

サーバーから何を送信するかを制御できるため、上記のデータ構造を拡張できます。ただし、クライアント側でノード ID に基づいて子ツリーを取得する簡単な方法が必要です。

編集:別のデータ構造、{id, []ids} のマップを保持することを検討しています。ここで、ids はルートからの順序付けられたパスです。より良い方法はありますか？

4

2 に答える 2

1

JavaScript のオブジェクトは真のポインタベースのオブジェクトです。つまり、メモリをあまり消費せずにオブジェクトへの複数の参照を保持できます。サブオブジェクトを新しい ID ベースの親オブジェクトに割り当てるために単一のトラバーサルを実行しないのはなぜですか? 階層オブジェクトが単純に巨大でない限り、これは非常に高速です。

ベスト プラクティスと、構築しているアプリケーションが何百万ものユーザーにスケーリングされた場合に何が起こるかを考慮して、サーバーにもっと多くの作業をさせることが本当に必要かどうかを再考する必要があります。クライアントのコンピューターはそこにあり、リモート コンピューティング パワーを無料で提供する準備ができています。ワークロードをサーバーに移動して、1 秒あたりのクライアント要求の処理を減らすのはなぜですか? それはあなたが望む方向ではないかもしれません。

これは、このインデックス構築手法を示すフィドルです。一度それを実行し、好きなように何度もインデックスを使用します。上記のインデックスを作成するのに 4 ～ 5 ミリ秒しかかかりません。性能問題なし！

もう 1 つ注意: 帯域幅に関心がある場合、それを支援する簡単な方法の 1 つは、JSON を切り詰めることです。オブジェクト キー名を引用符で囲んだり、1 文字のキー名を使用したり、空白や改行を使用したりしないでください。これにより、非常に大きな改善が得られます。サンプルの JSON にこの変更を加えると、11,792 文字から 5,770 文字になり、元のサイズのわずか 49% になります!

JavaScript のオブジェクト キーは常に文字列であることに注意してください。JSON の例に追加した数値 ID は、キー名として使用されると強制的に文字列になります。これは使用上の障害にはなりませんが、注意が必要な微妙な違いです。

于 2012-09-27T17:54:41.090 に答える
0

ID が何らかの形で順序付けられているとは思いませんが、各ノードにその子 (およびサブ... ）。

これはサーバー側で非常に簡単に実現でき、ツリーを検索するときに、探している ID がノードの ID 範囲内にあるかどうかを確認してから、内部に足を踏み入れてすべての子を検索できます。

于 2012-09-27T17:15:13.930 に答える