通知機能を作る上で、通知専用テーブルは不要ではないでしょうか？

Question

通知機能について知りたいです。
なぜ通知専用のテーブルが必要なのでしょうか？

---

通知機能を調べていると、次のように「通知を送ったデータ」という通知専用のテーブルを作る方法を見つけました。

ntf_id	visitor_id	visited_id	post_id	action	kidoku
通知のid	した人のid	された人のid	された投稿のid	like	false

でも疑問なのですが、上だけでなくいいね等の「アクションのデータ」のテーブルも絶対ありますよね。このような↓

act_id	visitor_id	visited_id	post_id	action
アクションのid	した人のid	された人のid	された投稿のid	like

で、この「アクションのデータ」に以下の「kidoku」という既読状況のカラムだけ入れれば、あとはこれが通知テーブルとしても使えると思うのですけど、

act_id	visitor_id	visited_id	post_id	action	kidoku
アクションのid	した人のid	された人のid	された投稿のid	like	false

何か不都合ありますか？
どうして「アクションのデータ」とは別に「通知を送ったデータ」のテーブルが必要なのでしょうか。どういうときに役に立ちますか？

Comments

[papinianus]

> 上だけでなくいいね等の「アクションのデータ」のテーブルも絶対ありますよね
絶対にあると思う理由を教えてください。

[gachapon]

いいね機能の作り方を見ると「アクションのデータ」のテーブルの作り方が載っているからです。片方あればいいということでしょうか？通知テーブルもアクションテーブルも必要だと思いますか？

Answer 1

そのサービス上でユーザーに通知するアクションが「いいね」一つだけである場合は、通知用のテーブルをわざわざ作らなくても良いかも知れません。

しかし、将来そのアクションが増えていく（例えばフォローされました、メッセージが届きました等）場合、もし通知テーブルが無いと、通知するために各テーブルからデータを取得し、連結し、日付順に並べ替える必要があります。

ユーザーに表示する通知内容の最新の10件を表示し、その後はページネーション、といった形で見せようとしたいときは、毎度それぞれのテーブルに問い合わせをして、並べ替えして、という処理が繰り返されるため、複雑になる可能性があります。

そう考えると、通知用に一つテーブルを持っておけば、様々なお知らせを一箇所に集約して、常に最新の10件を取得すれば良いだけなので、シンプルな処理で済みます。

そのサービスを将来どのような設計にしていきたいかで、必要か不必要かは判断は分かれると思います。