MySQLユーザーがファンテーブルの設計案に注目することについて考える

シナリオ1

follow(関心関係表)

フィールド名
を選択します.
索引
注釈
id
primaryKey()                             
user_id
integer()->unsigned()->notNull()
normal
ユーザー
followed_user
integer()->unsigned()->notNull()
 
注目する人のid
status
smallInteger()->unsigned()->defaultValue(1)
 
注目状態:注目を取り消すかどうかなど
created_at
integer()->unsigned()->notNull()
normal
updated_at
integer()->unsigned()->notNull()
normal
ユーザーが関心を持つたびに、テーブルにデータが追加されます.
メリット:
1.設計が簡単で、検索が便利である.注目する一人一人を区別して特殊な処理(例えば、異なる人の注目イベント、互いに粉を塗っているかどうか、特に注目しているかどうかなど)を行うことができ、3.コードを書きやすい.
欠点:
ユーザ量が大きいとテーブルデータ量が膨大になるため,ユーザを複数のテーブルに分散させるために水平分割テーブルを用いる必要がある.
例えば、10万人のユーザがいて、IDが1~10000のユーザが表1(follow_1)に、IDが10001~20000のユーザが表2(follow_2)に、このようにしている.
しかし、表を分けるともう一つの問題に直面し、注目される人が複数の表に基づいて自分のファンを調べるのは面倒だ.ファンテーブルを再構築する必要があります

ファン(ファンリスト)

フィールド名
を選択します.
索引
注釈
id
primaryKey()
user_id
integer()->unsigned()->notNull()
normal
ユーザー
follower
integer()->unsigned()->notNull()
 
ファン人
status
smallInteger()->unsigned()->defaultValue(1)
 
注目状態:注目を取り消すかどうかなど
created_at
integer()->unsigned()->notNull()
normal
updated_at
integer()->unsigned()->notNull()
normal
このデータテーブルは依然として水平テーブル処理が必要です.
シナリオ2

follow(関心関係表)

フィールド名
を選択します.
索引
注釈
id
primaryKey()
user_id
integer()->unsigned()->notNull()
ユニーク
ユーザー
followed_user
text
 
注目する人
follower
text
 
ファン人
created_at
integer()->unsigned()->notNull()
normal
updated_at
integer()->unsigned()->notNull()
normal
各ユーザーが注目している人とファンをjson形式で記録する
メリット:
1.ユーザーごとに1つのレコードしかありません.簡単な検索
欠点:
1.ファンの数や関心が大きすぎる場合、followed_userフィールドとfollowerフィールドのデータ長は非常に大きく、ユーザーが注目している人やファン数が10万人に達すると、1つのデータのデータ量がメガレベルに達し、mysqlのクエリーとphpデータ処理の効率を大幅に低下させます.
2.このテーブルを使用するたびに、データ全体を取り出して計算し、リソースの消費量がかかりすぎます.
シナリオ3
redisを使用したHashデータ型
Redis hashはstringタイプのfieldとvalueのマッピングテーブルです.Redis内の各hashは、232−1キー値対(40億以上)を記憶することができる.
各ユーザはhashテーブルを1枚分け、テーブル名はユーザid(接頭辞または接尾辞を付けることができる)
ユーザが一人に注目するたびにhashテーブルにデータを追加する

field:      id

value：    

user_1

field
value
2
1483423443
3
1483423445
13
1483423440
...
...

user_2

field
value
1
1483423443
5
1483423445
10
1483423440
...
...
......
メリット
1.クエリーの処理速度が速い.
欠点
1.サーバメモリとCPUを消費する.Redisを実行するには、個別のサーバを使用することが望ましい
2.データ・クエリーは、リレーショナル・データベースほど柔軟ではありません.
3.開発手順が複雑で、学習コストが高い.

CREATE TABLE relation (
id PRIMARY KEY AUTO_INCREMENT, //  ，  
from_user_id big integer, //    A   id
to_user_id big integer,//    B   Id
rel_type enum(1,2) //    
);

ブラックアウト/ファン/注目、データベースに保存されているのはマッピング関係の数字です.例えば、ブラックアウトは1で、ファン/注目は1つのもので、2です.では、記録の重要なデータは次のとおりです.

from_user_id//このレコードはどのユーザーが

を開始したかを記録します.

to_user_id//本条記録の受付先はどのユーザー

ですか

rel_type//発起者が受け入れ者に対して、何をしましたか?保存タイプ

シーンの例:
ユーザAは、ユーザBに注目する
データの挿入:

INSERT INTO relation (rel_type, from_user_id, to_user_id) VALUES(2, A.id, B.id)

ユーザーAのファン数:

select COUNT(*) from relation 
where rel_type=2 and to_user_id=A.id;

ブラックリストは同じだ.
これはあなたが与えた表に従って処理されます.私自身がデザインをしていたとき、実は注目/ファンに時計を作って、ブラックリストにまた時計を作ったのです.自分のニーズや習慣に従えばいいので、どちらを選ぶかは関係ありません.