最近打算实现一个通知系统。
就像差不多。
比如那个人顶了你的答案。
那个人采纳了你的答案等。
而这些情况很多的时候
如何去设计数据库的字段呢？
保存的时候需要保存关系吗？还是直接生成一个消息。显示消息就行了？？
最近做这个。好迷茫的感觉
可以使用 redis 的集合.
首先设置各种事件,比如
0:关注
1:采纳
2:赞
3:邀请
redis 中每个人的有一个集合. uid 为集合名
假设有如下事件:
1.用户 A 赞了你在某个题目下的回答.
2.用户 B 邀请你回答某个问题
redis集合中就保存:
0:Auid:问题id
3:Buid:问题id
谢邀。本人也没有相关经验。
建议保存关系，这对以后的数据分析比较有利。
redis是应用层面的优化，可以参考一下@悲惨的大爷 的答案。
SQL表有2种维度：
第一种：只记录用户的关注, 采纳, 赞, 邀请的数量
id(pk) | user_id | count | type(user_id + type)做唯一索引；
优点：简单；
缺点：只能看到用户收到多少关注，但不知道收到谁的关注；
第二种：
在第一种的基础上把count字段换成another_user_id(这个名称不好，随便想的，不要参考)(user_id + another_user_id + type)做唯一索引；
优点：可以知道该用户被谁关注了；
缺点：表数据量增长会很快，容易上千万甚至亿级，而且不便统计（性能差）；
但第二种的缺点也不是不可解决，分库分区、水平分表、另起一个表专门存储统计数据等等，若干方法，等有需要的时候再考虑这个问题吧。
以上方案，视乎你们对业务的需求吧。
可能有更好的方法，此处仅供参考。