请教一个 mongo 的数据库设计问题

[no13bus]

项目来源于我自己的开源项目 https://github.com/no13bus/ohmyrepo

它利用了github的webhook功能，自动获取用户的repo的star信息，关注人的分布以及关注者的被follow的数量排名， 这样你可以选择直接follow他们。
现在仔细想了想数据库构造，觉得还是有点问题。想请教下大家。



上面是mongo的数据库基本构造
有2个collection 一个是user 一个是event。

user存储的是用户名以及其github的token。

event存储的是star用户自己的项目时候的事件信息，username和user里面的username是一个东西，其中主要的是sender，他又包括了star项目人的用户名(sender_name) 该人的follower数量(followers)，以及其所在地点(location).

项目需要查询的是用户(username)自己的项目(reponame)的所有的star的人的地点分布，以及该项目的star人的followers的数量排名。

我自己这么设计数据库的时候发现，如果一个人star了多个项目的时候，那么event里面应该会出现多次一样的sender。应该单独设置一个sender表，想来去想去就又跑到关系数据库的思维方式里面去了。

想问下大家，应该如何设计这样的数据库呢？

[no13bus]

没人知道吗？还是说我问题没有描述清楚？

[luw2007]

不需要增加一个表。

User应该包含了 sender的信息 location, followers。
Event 中直接存储 User._id, 即可。

[wangshuai]

这个问题吧，我认为， 其实 Event 表 可以理解成一个 log 的表，记录Star事件的，所以你说的那些统计内容，也就是吧event 表当个样本池子，是需要对Event表做类似 map－reduce的处理来获取分布啊之类的信息。
具体表的设计方面，我觉得也就是加一个类似 RepoPopular之类的名字的表，里面存放Repo的信息和username之外，应该有一个 senders 的 array ， array 里面存放所有star过这个repo的人信息，比如名字，followers， 和location，是一个 document的array。 当你在为这个repo统计的时候，直接find这个reop，那所有和你统计相关的所有star的人的信息就都有了。

只不过是在update 这个 document的时候，程序那里通过代码来控制一些约束，比如什么重复人啊，之类的。

如果是持续运营阶段性的数据，就不用map－reduce，直接find document 搞就可以。 如果是一次批量取得很多数据，然后store 进 mongo， 那就搞的map－reduce， 稍微复杂一点的统计，就用这种方式基本很多问题都可以解决。

[wangshuai]

@wangshuai 当人需要考虑单个document 16m 的那个 limit，不过应该没啥问题吧， 一个repo，到不了那么多人去star。

[no13bus]

@wangshuai 是的。没有那么大。你这样的设计是符合mongo的设计思路的，之前也这么想过，但是觉得一个repo的信息都塞到一个docement里面有点大，可能是一个repo有1w个star的话，数据量有点大，不知道这样查询会不会慢，本身map-reduce查询就慢，消耗性能。我用的是aggregate来做的分组和归类。

能加你qq聊聊吗？我的是364416072

[no13bus]

@wangshuai 其实如果使用mongo的那种设计方式的话，会存在这种情况。如果一个人star了多个项目的话，会发现在RepoPopular这个表里面会发现，有2个repo的senders这个array里面会有相同的star repo的相同的一个人的信息。如果是关系数据库的话，应该就不是这样了。
还有一个问题是，一个人的followers的数量信息其实是会变化的，一般是会增大的，目前我的项目里面默认这个数就是最开始的爬取时的followers的数量信息，不会后续更新的。如果是要更新的话，其实很麻烦，需要找到各个repo里面该用户，然后全部更新。