データ構造 - mysql データベース トラバーサルに関する PHP の問題

エージェント分散システムに関するアルゴリズム最適化問題

たとえば、エージェントのレベルはゴールド、シルバー、ブロンズの 3 つのレベルに分かれています。私は現在ゴールド エージェント A ですが、同時にシルバー エージェント B、C、D を開発しました。シルバー エージェント b はブロンズ エージェント E を開発しました。と F、図に示すように:
A 従属エージェントのリスト
╦═══════
║
╠═ b
║ ╠══ e
║ ╠══ f
╠═
╠ ═d
今、プログラムを使用します。上記のような例を作成します。図の方法は次のとおりです: (PHP+MYSQL)
まず、上位エージェントが A であるすべてのエージェントを検索します。
たとえば、エージェント B が見つかった場合は、すべてのエージェントを検索しますその上位エージェントは B です。この検索は完了しました。
エージェント C を再度検索…………
など。

質問:

これで、エージェント データベースには 300,000 のレコードが存在します。各エージェントは、エージェント分散システムで自分の従属エージェント ツリーを表示できます。
エージェントに 1,000 の従属エージェントがある場合、すべての検索に時間がかかります。全く表示されなくなります。

---

私が思いついた解決策は、配列を使用してすべてのユーザー関係を保存し、ユーザーが追加または削除されるたびに、この配列をファイルとして保存することで、同時に配列が更新され、必要なデータが更新されます。は配列から走査され、データベースに直接アクセスして選択を実行するだけです。 。この方法は実現可能でしょうか?他の解決策はありますか?

トラバース

---

上位レベルのメンバーから下位メンバーを見つけたい場合は、トラバーサルを使用します。このアルゴリズムは、視覚的にデータベースに何度もクエリを実行します。 。 。リソースを大量に消費します。代替手段はありますか?キャッシュ？レディス？

返信内容:

エージェント分散システムに関するアルゴリズム最適化問題

たとえば、エージェントのレベルはゴールド、シルバー、ブロンズの 3 つのレベルに分かれています。私は現在ゴールド エージェント A ですが、同時にシルバー エージェント B、C、D を開発しました。シルバー エージェント b はブロンズ エージェント E を開発しました。と F、図に示すように:

A 従属エージェントのリスト

╦═══════
║
╠═ b
║ ╠══ e
║ ╠══ f
╠═
╠ ═d
今、プログラムを使用します。上記のような例を作成します。図の方法は次のとおりです: (PHP+MYSQL)
まず、上位エージェントが A であるすべてのエージェントを検索します。
たとえば、エージェント B が見つかった場合は、すべてのエージェントを検索しますその上位エージェントは B です。この検索は完了しました。
エージェント C を再度検索…………
など。

質問:

これで、エージェント データベースには 300,000 のレコードが存在します。各エージェントは、エージェント分散システムで自分の従属エージェント ツリーを表示できます。

エージェントに 1,000 の従属エージェントがある場合、すべての検索に時間がかかります。全く表示されなくなります。

私が思いついた解決策は、配列を使用してすべてのユーザー関係を保存し、ユーザーが追加または削除されるたびに、この配列をファイルとして保存することで、同時に配列が更新され、必要なデータが更新されます。は配列から走査され、データベースに直接アクセスして選択を実行するだけです。 。この方法は実現可能でしょうか?他の解決策はありますか?

---

トラバース

上位レベルのメンバーから下位メンバーを見つけたい場合は、トラバーサルを使用します。このアルゴリズムは、視覚的にデータベースに何度もクエリを実行します。 。 。リソースを大量に消費します。代替手段はありますか?キャッシュ？レディス？

---

階層的なクエリ、オンデマンドでデータのクエリを行うことをお勧めします。一度に関係ツリーを表示するには、多くのクエリが必要になり、リソースが消費されます。

そのような実装では、無限のレベルの分類を確認し、左右の値の原則を使用して、ショッピングモールの分類の原則と同じ順序のツリー構造です。

まず、プロキシレベルがインデックス化されているかどうかを確認します。

ツリー全体を 1 ページに表示するのは適切ではありません。オンデマンドでクエリできます。

ゴールド エージェントはページを開き、部下のすべてのシルバー エージェントを表示します。シルバー エージェント ユーザーをクリックすると、部下のブロンズ エージェントが表示されます。

ご招待ありがとうございます。私のアイデアをいくつか共有させてください:

更新頻度がそれほど高くない場合は、

(データ量は 300,000 で、レベル 1 ～ 2 までしかキャッシュできないと推定されます) を使用すると、毎回 SQL クエリを使用する必要はありません。

1. 複数回ロードされる 前述のように、最初に

   をロードします。 缓存

2. ツリー構造の無限分類N级的，等点击后，再ajax去请求N+1级

   具体的な答えは自分で探してください。詳しく説明するのは非常に面倒です。一般的な原則を説明します。
   部下が誰であるかをできるだけ早く知るにはどうすればよいですか?全員が列に並んだ場合は、次の 2 つの条件を満たすだけです: 1- 誰が最初であるかを知っている、2- 自分が最後であることを確認する (もちろん、誰が最後であるかを知っていて、自分が最初であることを確認することもできます)
   これによると、 select * from Tree whereindexNumber >= search.node.min &&indexNumber のように、各ノードに適切なシリアル番号を割り当てることで高速な検索が実現できることが推測できます。

   最終的なテーブル構造は
   id、parent_id (親ノード)、top_id (ルートノード、複数のツリーがある場合)、indexNumber (ツリー内のインデックス番号、top_id+indexNumber は一意です)、min (私は Benchmark、この枝の下で最初の人は誰ですか)、レベル (木の高さ)

   あなたの例では、これは似ているはずです（括弧内の最初の数字はインデックス番号、2番目は最小値、3番目は木の高さです）

   リーリー

   この構造は、ノードを操作する場合にはさらに複雑になります (たとえば、f の後に g を追加するか、f を削除すると、abcd はシーケンス番号を再計算する必要があります) が、一般に検索は 1 回で非常に高速に結果を取得できます。検索。