1

私が構築しようとしているアプリには、(users テーブルに格納された) ユーザーが存在し、ユーザーは互いに「接続」できます (たとえば、Facebook で友達になるなど)。私がやろうとしているのは、これらの接続を格納するためのデータ構造を構築することです。データは主に、ユーザーの「接続」(Facebook の友達など) テーブルを表示するために使用されます。これまでのところ、それを行うための2つの異なるアプローチに出くわしました:

  1. すべての接続 (友達など) を持つ各ユーザーのテーブルを作成します。
  2. Web サイト内のすべての接続を表す 1 つのテーブルを持つ (例:

[行 1 = ジョン・カイル]

[行 2 = カイルボブ]

[行 3 = リリー ジョン]

等....）。

私の質問は、どちらがより効率的かということです (主にクエリ時間の点で、サイズの点でも)。2 番目のものはサイズがはるかに小さいと思いますが、クエリに時間がかかると思います...どう思いますか? どちらを使用するのが良いですか？どちらのモデルがより広く使用されているか (特に Facebook や Instagram などの人気のある Web サイトで) わかっている場合は、それも大いに役立ちます!

4

2 に答える 2

1

パフォーマンス以外にも、最初のアプローチを採用しない正当な理由がありますが、このアプローチでパフォーマンスが向上する可能性はほとんどありません。

  1. DBMS は、多数のテーブルの中から最初に適切なテーブルを見つける必要があり、その後で初めてそれを検索できます。
  2. 1 回のインデックス シークで 1 つのテーブルを検索できます。

したがって、テーブル + 小さなインデックス シークと 1 つの大きなインデックス シークの検索があります。テーブルの検索は、大規模な B ツリーの「上半分」が下降するよりも高速になる可能性は低く、多くの個別のテーブルは多くの「スラック」(つまり、完全に満たされていないページ) につながる可能性があり、キャッシュの有効性が低下します。 . これらの両方の理由から、(2) の方が高速である可能性があります。

于 2012-07-31T15:20:00.907 に答える
0

すべての条件を備えた 1 つのテーブル。各行にはユーザー a 、ユーザー b 、接続タイプがあります。ここで、接続タイプは、接続タイプをリストした別のテーブルへの参照です。適切なインデックスを追加します。

于 2012-07-31T13:57:03.727 に答える