通知的数据库表结构，例如社交网站的表 [英] Database table structure for notifications like table for a social networking site
问题描述
我正在开发一个类似Facebook的社交网站。我很困惑如何为通知表创建结构。对于每个用户来说应该是单独的，还是对于经常添加和删除的所有地方来说，它是一个庞大的记录？
I am developing a social networking site like Facebook. I am confused how to create structure for notification table. Should it be separate for each user or a huge one for all-where records added and deleted frequently ?
推荐答案
问题，并发现了这个（找到了）在研究给定的表结构在哪里之后：
I have the same problem as you and found this (found this) upon researching where the table structure given is :
id
user_id (int)
activity_type (tinyint)
source_id (int)
parent_id (int)
parent_type (tinyint)
time (datetime but a smaller type like int would be better)
其中：
activity_type 告诉我活动类型， source_id 告诉我该活动相关的记录。因此，如果活动类型的意思是添加了收藏夹，那么我知道 source_id 是收藏夹记录的ID。
activity_type tells me the type of activity, source_id tells me the record that the activity is related to. So if the activity type means "added favorite" then I know that the source_id refers to the ID of a favorite record.
> parent_id / parent_type 对我的应用程序很有用-它们告诉我活动与什么相关。如果喜欢一本书，则parent_id / parent_type会告诉我该活动与具有给定主键（id）的一本书（类型）相关
The parent_id/parent_type are useful for my app - they tell me what the activity is related to. If a book was favorited, then parent_id/parent_type would tell me that the activity relates to a book (type) with a given primary key (id)
我在（用户ID，时间），并查询用户ID IN（...朋友...）和时间>临界点的活动。放弃id并选择其他聚簇索引可能是一个好主意-我还没有尝试过。
I index on (user_id, time) and query for activities that are user_id IN (...friends...) AND time > some-cutoff-point. Ditching the id and choosing a different clustered index might be a good idea - I haven't experimented with that.
很基本的东西，但是它很有效，很简单，并且随着需求的变化，它很容易处理。另外，如果您不使用MySQL，则也许可以在索引方面做得更好。
Pretty basic stuff, but it works, it's simple, and it is easy to work with as your needs change. Also, if you aren't using MySQL you might be able to do better index-wise.
它还建议在那里使用 Redis 可以更快地访问最新活动。
混合使用Redis，它可能会像这样：
It also suggested there to use Redis for faster access to the most recent activities. With Redis in the mix, it might work like this:
- 创建MySQL活动记录
- 对于创建该活动的用户的每个朋友，将ID推送到他们在Redis中的活动列表中。
- 将每个列表修剪到最后X个项目
Redis速度很快，并且提供了一种通过一个连接传递命令管道的方法-因此将活动发送给1000个朋友需要毫秒。
Redis is fast and offers a way to pipeline commands across one connection - so pushing an activity out to 1000 friends takes milliseconds.
有关我在说的内容的详细说明，请参见Redis的Twitter示例： http://code.google.com/p/redis/wiki/TwitterAlikeExample
For a more detailed explanation of what I am talking about, see Redis' Twitter example: http://code.google.com/p/redis/wiki/TwitterAlikeExample
我希望这也可以对您有所帮助
I hope this might help you also
这篇关于通知的数据库表结构，例如社交网站的表的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
