LinkedInでは、誰かのプロフィールにアクセスすると、その人とどのようにつながっているかを確認できます。LinkedInは、3レベルまでの接続を示していると思います。
shabda-> Fooユーザー、barユーザー、bazユーザー->Joelの接続->Joel
これをデータベースでどのように表現できますか。
としてモデル化すると、
ユーザー Id PK 名前文字 繋がり User1 FK User2 FK
次に、3レベルの深さのネットワークを見つけるために、すべての接続、それらの接続、およびそれらの接続を取得し、現在のユーザーがそこにいるかどうかを確認する必要があります。これは明らかに、どのサイズのDBでも非常に非効率的であり、おそらく同様に機能するのは不格好です。
リンクインでこのネットワークを見ることができるので、私がアクセスするどのプロファイルでも、これも事前に計算されているとは思いません。
私の頭に浮かぶもう1つのことは、おそらくこれはリレーショナルDBに格納しないのが最善であるということですが、それを格納および取得するための最良の方法は何でしょうか。
グラフデータベースを使用することをお勧めします。現在利用可能な実装は1つだけのようで、それがNeo4jです。Javaで書かれていますが、RubyとScala（Pythonが進行中）にバインドされています。
Javaを知らない場合は、残念ながら、他のプラットフォームでは（まだ）類似したものを見つけることができないでしょう。ただし、Javaを知っている（または少なくとも学習する意思がある）場合は、それだけの価値があります。（技術的には、Ruby / PythonバインディングのためにJavaを学ぶ必要さえありません。）Neo4jは、まさにあなたがやろうとしていることのために構築されました。ほんの数行のJavaコードでまったく同じことを、さらに効率的に実行できる場合、リレーショナルデータベースにこれを実装しようとすると、多くの問題が発生します。
それが不可能な場合でも、オブジェクトデータベースなどの他のデータベースタイプを調べることをお勧めします。リレーショナルデータベースはこの種の目的のために構築されたものではなく、別の種類のデータベースに切り替えて学習するよりも、RDBMSでそれを実行しようとするとより多くの苦痛を経験することになります。
これにリレーショナル データベースを使用することに問題がある理由がわかりません。質問で定義されたテーブルは、優れた出発点です。適切な最適化を行うことで、パフォーマンスを良好に保つことができます。個人的には、このような用途の広い主流製品からの移行を正当化するには、何か真剣なものが必要になると思います. いずれにせよ、プロジェクトにはおそらく RBDMS が必要であり、多くの価格帯 (無料であっても) で比類のない量の正当な選択肢があります。質の高いドキュメントが提供され、サポートが利用可能になり、ジョブプールで利用できる高度に訓練された開発者が大量に供給されます。
この自己関係のモデル (ユーザーが他のユーザーに参加する) に関しては、再帰クエリを検討することをお勧めします。これにより、個々のクエリをカスケードして 3 レベルの関係を見つけることができなくなります。CTE を使用して再帰クエリを実行するには、次の SQL Server メソッドを検討してください。
http://msdn.microsoft.com/en-us/library/ms186243.aspx
MAXRECURSION ヒントを使用して、どのくらい深くするかを指定できます。
次に、最適化の方法を考え始める必要があります。それは、適切なインデックスとメンテナンスなどを使用してテーブルを設定するための標準的なベストプラクティスから始まります。必然的に非正規化で終わります。これは、他のすべてを試した後にのみ行うことの 1 つですが、何を行っているかを理解し、適切なプラクティスを使用すれば、パフォーマンスが大幅に向上します。インターネット上には、非正規化について学ぶのに役立つリソースがたくさんあります。調べてみてください。