グループ化フィールドも必要です

実際、物事を複雑にしすぎる必要はありません。必要に応じてゆっくりと進めてください。

これは私のフォロー機能のテーブル構造です。参照してください。

 ユーザー関係:
    タイプ: オブジェクト
    プロパティ:
      ID:
        型: 整数
        説明: ID
      ユーザーID：
        型: 整数
        説明: ユーザー ID
      ターゲットユーザーID:
        型: 整数
        説明: 対象ユーザー ID

非リレーショナル データベース

ここでデザインするときにグループの機能を考慮し、2 人の友人関係もグループに変換しました。

ページ全体に 3 つのテーブルが必要です

1 つはユーザー テーブルです
1 つはグループ テーブルです
もう 1 つはユーザーとグループの対応テーブルです

3 つのテーブルを通じて決定

私の知る限り、Weibo の注目はこのように設計されています。

以前、テーブルの設計に関する質問を見たことがあります。ユーザー テーブルでは、ストレージをカンマで区切るには 1 つのフィールドを使用するか、ストレージを関連付けるには 2 つのテーブルを使用しますか?実現可能

これで十分です

しかし、クエリも問題です。redis はこのタスクに非常に適しています。

双方向の友人であるかどうかを示すフラグ フィールドを追加できるかもしれません

多対多の関係である必要があります。
ユーザーは複数の友達を持つことができます。
複数のユーザーから友達として追加することもできます。
リレーショナル データベースにおける多対多の関係は、通常、中間テーブルを使用して実装されます。
現時点では、中間テーブルには通常、ユーザー ID とフレンド ID のみが格納されます。ただし、業務実装の便宜上、中間テーブルに検証パス、フレンドグループID、ソート番号などを追加することができます。
この多対多中間テーブルと一般的な多対多中間テーブルの違いは、多くの場合、この関連付けテーブル自体がそれ自体です。つまり、ユーザー テーブルとユーザー テーブル間の多対多の関係です。