兄弟、各 QQ にどのようにさまざまな友達がいるかを話し合いましょう。データベースをどのように設計すればより便利になるでしょうか。

各 QQ にどのようにさまざまな友達がいるかを説明します。データベースをどのように設計すればより便利になるでしょうか。
各 QQ にどのようにさまざまな友達がいるかを話し合いましょう。データベースをどのように設計すればより便利になるでしょうか?

それは私の能力を超えているはずです。どのようなアイデアがあるのか​​知りたいです...
-----解決策------------- -------
2 つのフィールドのテーブル
10,000 の QQ がすべてフレンドである場合、レコードの数はわずか 1 億です
実際には、10 分の 1 にも到達しません。
------解決策--------------------------------
id myid friendsid

完了しました。

これはセットアップに最適な方法であり、サーバー要件が最も低くなります。


-----解決策---------
2 つのテーブルを使用する A qq table リレーショナル テーブル
-----ソリューション--------
1. QQ メンバーシップ テーブル
には、ユーザー
id、nickanme などごとに 1 つのレコードがあります。

2. QQ フレンド関係テーブル
id、myid、friendid

3. QQ ブラックリスト テーブル
id myid blackid

4.ユーザー ID に応じてサブテーブル
を使用することをお勧めします。たとえば、id=5000 のユーザーのサブテーブルは 5000/2000 になり、四捨五入されます。つまり 2 であるため、テーブルは message_0002
id fromid, toid,message, addtime.


------解決策------ -------------
テーブル。
CREATE TABLE `qq_friends` (
`my_id` bigint(13) NOT NULL,
`friend_id` bigint(13) NOT NULL,
`is_black_id` tinyint(1) NOT NULL DEFAULT '0 ',
`add_date` TIMESTAMP(10) NOT NULL,
PRIMARY KEY (`my_id`,`friend_id`),
KEY `my_id` (`my_id`),
KEY `add_date` (`add_date`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

テーブル ロックの代わりに行ロック、InnoDB を使用することをお勧めします
自動インクリメント ID を放棄します (何をしますか)
PRIMARY KEY このQ IDとフレンドIDの組み合わせを設定します
このQ IDと参加時刻にそれぞれインデックスを付けます
is_black_id (ブラックリストに登録するかどうか、0、 1階に記載の通り、クロスレコードなので1万人のQQユーザー全員がフレンドになったとしてもレコード数は1億件しかありません(実際はもっと少なくなります)、しかしデータベースは素晴らしいものになるでしょう。したがって、サブデータベースまたはデータベース クラスター (100 万の数値ごとに 1 つのデータベース、複数のデータベースに対して 1 つのサーバー) を検討する必要があります。