0

WebアプリがTwitterから取得したメッセージをローカルデータベースに保存する必要があります。メッセージを保存する目的は、これらのメッセージを階層順に表示する必要があることです。つまり、アプリケーションを介してユーザーが入力した特定のメッセージ（つまり、ステータスの更新）は、他のユーザーの子ノードです（親メッセージのサブリストアイテムとして表示する必要があります）。 ）。隣接リストモデルまたは入れ子集合モデルのどちらを使用する必要がありますか？4種類のメッセージを管理する必要があります。各カテゴリのメッセージには2つの子ノードがあります。ここでもう1つ質問があります。どちらの場合も、入力が手動で制御されていることがわかります。つまり、隣接モデルまたは右、左の親ノードへの参照がネストされたリストに表示されます。私のアプリは、次のようにTwitterからメッセージデータをフェッチします。

foreach ($xml4->entry as $status4) {
       echo'<li>'.$status4->content.'</li>';
       }

したがって、マニュアルはなく、いつでも任意の数のメッセージを利用できます。どうすればそこからのメッセージ間で親子関係を作ることができますか。現在、ユーザーは4種類のメッセージに対応するさまざまなウィンドウにメッセージを入力します。私のアプリはキーワードを追加し、それらをフェッチして差分ウィンドウに表示します。これらのメッセージはすべて、現時点では親メッセージです。次に、別の子としてデータベースに保存できるメッセージをユーザーに入力させる方法を説明します。

4

2 に答える 2

2

http://dev.mysql.com/tech-resources/articles/hierarchical-data.html

（各ルートノードから開始して）データのツリーが多かれ少なかれ深い場合は、ALが遅くなるため、ネストされたセットの使用を検討してください。

于 2010-11-19T09:02:39.763 に答える
1

あなたが言う時

ツリーの深さは2ノードです。つまり、各親メッセージは2つの子ノードを持つことができます。

混乱します。

2つの子ノードのそれぞれにさらに多くの子を含めることができる場合は、深さではなく、ノードのブランチの幅を考慮します。

1）実際の深さ= 2

最大深度が実際に2の場合（つまり、すべてのノードがルートに接続するか、2つのステップでゼロレベルのノードに接続します。つまり、各ノードには、親と祖父母以外の祖先はありません）、リレーショナルを使用することもできます。階層データを格納するために直接モデル化する（最大深度が低くてもそれほど悪くない自己結合を介して、またはデータを祖父母、親、子の3つのエンティティに分割することによって）

2）深さ>> 2

番号2が幅であり、深さが可変であり、潜在的に非常に深い場合は、ネストされたセットを調べてください。さらに2つの可能性があります。

  • ネストされたセットのアイデアを使用すると、階層データを格納するためにgeomタイプを調べることができます（利点はそれほど興味深いものではない可能性があります-いくつかの有用な演算子、単一のフィールド、おそらくより良いインデックス戦略）
  • 連分数（ネストされたセットに基づいて、tropashkoは、ネストされたセットの問題のいくつかを改善すると約束したので、面白そうな一般化を提供しましたが、実装しませんでした...独自のテストを行ってください）。
于 2010-11-19T09:28:58.970 に答える