私は数週間を費やしている単純な「ソーシャル ネットワーク」のメイン データベースとして MySQL を使用しています。
すべてのソーシャル ネットワークと同様に、ユーザーは、ソーシャルにするために友人とのつながりを必要とします。
私の理論は、userデータベースに別の列を追加して、接続と名付けることでした。そこで、コンマで区切られたユーザー ID の文字列を保存し、必要に応じて分割します。
私が持っていた別の理論は、まったく新しいテーブルを作成し、connections「user_1」と「user_2」の 2 つの列を使用することでした。次に、データベースは、友人を検索するときに、ID などを探して選択を実行します。
ただし、問題は次のとおりです。最も効率的なのはどれでしょうか。多数のユーザーをサポートする場合、オプション 2 を使用するのは危険ですか?
いくつかのアドバイスをいただければ幸いです。
ありがとう！
正規化された構造 (オプション #2) は、記述したデータのタイプを構造化するために非常に適しています。増え続ける ID のリストを分割するよりも、2 つの整数列を持つ狭いテーブルをクエリする方がはるかに効率的です。
さまざまな正規化形式について読むことをお勧めします: http://en.wikipedia.org/wiki/Database_normalization (「通常の形式」を参照)
2 番目のアプローチの方がはるかに優れています。テーブル「接続」を使用して、ユーザー間の関係を作成しています。このようにして、「n:m」関係を作成できます。ある種の接続タイプ (「恋愛」、「友人」) を追加したい場合は、文字列ではなくテーブルに簡単に追加できます。
別の利点があります。ユーザーが持っている接続の数について考える必要はありません。接続には何を使用しますか? varchar? _ text? _ 本当に毎回この混乱を解析したいですか? 接続を 2 回追加しないようにするにはどうすればよいですか?
tldr;: テーブルを使用して関係を示します。
オプション1はうまくいきません。別テーブルでどうぞ。
connections間違いなく呼び出される別のテーブルの方が簡単です。1 つの列に複数の値があると、データベースの目的に反します。オプション 1 で user1 のすべての友人を検索することを想像できますか?
MySQL は確かにオプション 2 で優れたパフォーマンスを提供できます。友人を選択して計算を行う方が簡単です。キャッシング、複数のサーバー、負荷分散などでできることはたくさんあります。
現実的に言えば、多数のユーザーに到達するまでに、システムを書き直して、途中で学んだすべての教訓を組み込むことになります。