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

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

それは私の能力を超えているはずです。あなたがどのようなアイデアを持っているのか知りたいです...

ディスカッションへの返信 (解決策)

2 つのフィールドのテーブル
10,000 人の QQ ユーザー全員が互いに友達である場合, するとレコード数は記録されます たったの1億件です
でも実際には10分の1にも届きません

id myid friendsid

完了です。

これは、サーバー要件が最小限で済む最適なセットアップ方法です。

QQ テーブルとリレーショナル テーブルの 2 つのテーブル

1. QQ テーブル
各テーブルは 1 つの
ID、nickanme などを使用します。

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

3. QQ black name テーブル
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) NULL ではありません、
主キー (`my_id`,`friend_id`)、
キー `my_id` (`my_id`)、
キー `add_date` (`add_date`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

テーブルロックではなく、InnoDB、行ロックを使用することをお勧めします
自動インクリメントIDを諦めます（何に使うのですか？サイズを調整しますか？）
PRIMARY KEY このQ IDとフレンドIDの組み合わせを設定します
この Q ID と参加時刻にそれぞれインデックスを追加します
is_black_id (ブラックリストに載せるかどうか、保存するのは 0, 1)
1 階でも述べましたが、クロスレコードなので、10,000 個の QQ はすべてお互いにフレンドであるため、レコード数はわずか 1 億件 (実際にはそれよりも確実に少ない) ですが、データベースも驚くべきものになります。したがって、サブデータベースまたはデータベース クラスター (100 万アカウントごとに 1 つのデータベース、複数のデータベースに 1 つのサーバー) を考慮する必要があります。

2 フィールド テーブル

10,000 人の QQ ユーザー全員が互いに友達である場合、レコード数はわずか 1 億件です
実際には 10 分の 1 にも達しません。私が考えすぎているようです。 。