実現したいこと
1ユーザ1000以上のレコードをもつ必要があるサービスを構築中です。
例えば、Twitterのフォロー/アンフォローのようなテーブル構築をしたいです。
【案①】
id | user_id | follow_user_id |
---|---|---|
1 | 5987 | 3654 |
2 | 5987 | 4342 |
3 | 5987 | 2232 |
: | : | : |
このようにするのが一般的だということは理解できます。
https://katakata-gym.com/blog/7lMlLHQCHBEfSseaEHuP
や
https://hit.hateblo.jp/entry/2016/05/09/131806
の記事を見ても、このように構築されています。
この構成だと更新や削除は簡単に行えますが、私はこれはしたくありません。
なぜなら、レコード数が膨大になるからです。
↑のようなDB構成にした場合、例えば、1000人をフォローしたら1000レコードが生成されてしまいます。
1人1000レコードx1000人=100万レコードも生成されてしまうのがネックに感じています。
【案②】
そうではなく、
id | user_id | follow_user_id |
---|---|---|
1 | 5987 | 3654,4342,2232, ... |
: | : | : |
というように、1ユーザ1レコードとして、1つのカラムの中にコンマ区切りで追記していく方法を思いついています。
こうした場合、1人1レコードx1000人=1000レコードしか生成されない点を評価しています。
※なるべくレコード数を減らしたいという観点。
この案でもいいのですが、もっといい方法があるかもしれないと思い、質問させていただきました。
背景が長くなってしまいましたが、質問内容としては、
Q. Twitterのフォロワーのように、1人のユーザが1000や2000個の情報を持つ必要がある場合、1人当たりのレコード数をなるべく減らすことに重点を置いた場合、【案②】以外のやり方でいい方法はありませんでしょうか?
以上、よろしくお願いいたします。


回答5件
あなたの回答
tips
プレビュー